What a credential status bridge is, and why a contract on another chain needs one

A smart contract on another chain cannot see a Solidus credential, so it needs a copy of one answer: is the credential still valid? This page explains the bridge that carries that answer, what it carries, what stays home and how a status travels.

The problem, stated exactly

A credential issued on Solidus lives on Solidus. A smart contract on Ethereum Sepolia cannot see it. A contract reads only its own chain. It cannot call another chain, and it cannot ask a server.

So a contract that wants to say "only holders of this credential may call this function" has nothing to read.

Copying the credential across once does not fix this. A credential changes. The issuer can revoke it. It can expire. A copy made last week still says "valid" about a credential revoked yesterday.

The contract needs one thing: an answer, stored on its own chain, to "is this credential valid right now?", kept current without the holder doing anything. That is a credential status bridge. It copies the status and not the credential, and it keeps the copy fresh.

What it carries and what stays home

A status message holds these fields:

• A status: active, revoked, expired or unbound.
• An expiry, as a Unix time. Zero means no expiry.
• A hash of the issuer. It is a hash of the issuer's DID, not the DID.
• A hash of the credential type. It is a hash of the type's name.
• The holder key. It is an address on the destination chain: an EVM address, or a Solana public key.

Three more items do bookkeeping. An export ID names this one export. It is a hash, and it differs on each chain, so one credential has a different ID everywhere. A flag says whether the issuer is currently accredited. A header carries a sequence number and the Solidus block height. The whole message is 156 bytes.

What stays home: the holder's DID, the issuer's DID, every claim inside the credential and every document. None of them is a field in the message, so none of them can reach a destination chain.

One fact about hashes matters here. A hash hides nothing that can be guessed, and there are few issuers and few credential types. Anyone can hash the likely ones and compare. So a destination chain does learn that a given address holds a credential of a given type from a given issuer. That link is public and permanent. This is why the holder signs a consent message for each export, and why Solidus rejects an export whose consent signature is invalid or expired.

How a status travels

1. Solidus queues a message. When an issuer exports a credential to a chain, or revokes one, Solidus records a status message in that same block. It carries the next sequence number for that chain. A revocation queues one message for every chain where the credential is active.
2. The validators sign. After the block commits, each of the four Solidus validators signs the message with its own attestation key. The signature covers the destination chain and the sequence number, so a signature made for Sepolia is useless on Fuji.
3. A gateway delivers. Our gateway gathers the signatures and sends the message to the mirror, a contract on the destination that stores credential status. Anyone can do this step. The signatures are public, and the mirror accepts a message from any caller.
4. The mirror checks, then stores. It requires the exact next sequence number, so a revocation cannot be skipped. It recovers each signer from the signatures and requires enough valid ones. On 2026-10-08 the API reported a threshold of 3 of 4 validators. Then it stores the record.
5. A contract asks the gate. The gate is a small library an integrator calls. It answers ok, or it gives a reason: no export, not active, issuer not accredited, expired or stale. Solidus also sends a heartbeat on a schedule, and the caller sets how old a heartbeat may be. If delivery stops, the gate returns stale and closes.

What you trust at each step is written on security. Live health per chain is on status.

See it in one command

The bridge API lists every destination. This run trims the answer to each chain's key and domain. The domain is the id Solidus uses for the chain. For the three EVM chains it equals the chain ID.

curl -sL https://bridge.solidus.network/v1/routes | jq -c '.chains[] | {key, domain}'
# {"key":"sepolia","domain":11155111}
# {"key":"fuji","domain":43113}
# {"key":"arc","domain":5042002}
# {"key":"solana","domain":1399811151}

This output is from 2026-10-08. The four chains are Ethereum Sepolia, Avalanche Fuji, Arc testnet and Solana devnet. All four are testnets. The full response also lists the mirror contract address on each chain.

To read a status from your own contract, go to check a condition without seeing the data. To see why a signature cannot be replayed on another chain, go to the destination is inside what is signed. The integration steps are on developers, and short answers are in the faq.