Category C is the honest one to explain. It is not CCIP yet, and we say so.
We map every chain we touch into one of three categories. Category A is the good stuff: Chainlink CCIP handles routing, the Cross-Chain Token Standard handles the token, and the trust model is whatever CCIP gives you (which is a lot, and it is not us). Category B is the middle ground: CCT works on the chain but CCIP does not yet route to it, so we wrap and the trust model is CCT's. Category C is the honest one to explain. That is what this post is about.
Category C is what we do when we want a chain that CCIP does not yet reach. Today that includes Stellar Soroban, Stacks, and Canton, and it may include others as we onboard them. The trust model is not "CCIP arrived here"; the trust model is "we ran a small, DON-attested relay until CCIP arrives." Everything in this post is about the guardrails that make that relay a defensible thing to run in the meantime, and the roadmap by which it eventually disappears.
What Category A gives you as a baseline
On Chainlink CCIP-native chains, the message is signed by the Decentralized Oracle Network (DON), the risk management network can reject a message before it lands, and the token pool contracts on each side share an enforcement surface. That is the baseline: the coordinator we would otherwise have to be is Chainlink's, not ours. On any chain in Category A, our job is to configure the pools and stay out of the way.
Category B is a smaller step down. The CCT-standard token contract still exists on both sides. The bridge is not CCIP-routed, but the token itself is the same shape as it would be under CCT, and the compliance surface is the same modular policy set we use everywhere on EVM. We are borrowing CCT's design without borrowing CCIP's routing.
What Category C actually is
Category C is the step where the destination chain does not run CCT or CCIP at all. Stellar's Soroban runtime is not EVM. Stacks Clarity is not EVM. Canton is not EVM. There is nothing to configure on the destination side that will accept a CCIP message today, because CCIP does not send messages to those runtimes yet. If we want to move a tokenized asset to one of these chains without waiting for that support to land, we have to run the transport ourselves.
The transport we run is a small relay powered by Chainlink CRE (Chainlink Runtime Environment). A source-chain event is picked up by a CRE workflow; the workflow's output is signed by the DON; the destination-chain contract accepts the mint only if the signature verifies and the payload is well-formed. The relay itself is not custodial in the sense of holding user balances; the lock happens in a source-chain vault we do not control unilaterally, and the mint happens on the destination chain only when the destination contract accepts it. What we do control today, honestly, is the schedule of the relay: the process that reads events, invokes the CRE workflow, and posts the mint transaction.
The relay is a courier. The lock is on the source. The mint is on the destination. Neither one is ours to fake.
The guardrails
A small, honest relay is only as good as the guardrails around it. We use three that matter.
Mint caps. Every OB-issued token has a per-period mint ceiling encoded in the destination-chain contract. The relay cannot mint above the cap, and only the token administrator (a multisig, not the relay) can raise it. If the relay is compromised or misused, the mint cap is the ceiling on damage before the next admin decision.
Replay protection. Each source-chain event carries a nonce, and the destination contract records which nonces have been used. Re-submitting the same event is refused by the contract, not by the relay's memory. A replay attempt costs gas and returns a specific revert; it does not silently succeed.
Address allowlist. The mint call requires the recipient to be admitted for that asset on the destination chain. The relay cannot decide whether a mint is allowed; only the destination-chain compliance layer can. This is what makes Category C consistent with the rest of the platform: the compliance layer holds on Category C the same way it holds on Categories A and B, using the destination chain's own primitives.
Return path: 2-of-2 for Stacks
The Stacks return path is worth calling out because it is not just a CRE workflow. Outbound from Stacks back to an EVM chain is DON-attested at the point of leaving Stacks, but the Bitcoin-anchored settlement side requires a second signer for release on the EVM side. That signer is a 2-of-2 arrangement between Hiro's Testnet4 service and a self-hosted OB Testnet4 node. Neither party can release alone. It is not decentralization; it is a two-party check against unilateral action while we wait for a broader signer set to make sense.
The roadmap
Category C is a bridge, in the ordinary sense of the word: something you use to cross a gap, and something you eventually retire when the gap is filled. There are two steps between "OB-operated relay today" and "Chainlink-native everywhere tomorrow."
The first is M-of-N. The single-operator relay we run today should become an M-of-N signer set, with membership drawn from partners we and Chainlink can both name publicly. This is not a decentralization claim; it is a reduction in unilateral risk, and it is a well-understood pattern. The second is CCIP-native. When Chainlink's cross-chain infrastructure reaches Soroban, Stacks, and Canton, our Category C relay for that chain is retired and the routing collapses to Category A. We would rather that day come sooner than later; nothing about the Category C relay is a business we want to be in.
Why we say all of this out loud
Every bridge failure of the last three years has been someone hiding the trust model. The lesson is that the honest way to build cross-chain rails for regulated assets is to name the trust model at every hop, publish the guardrails, and treat the fact that we run a relay as a temporary state to be reduced, not a marketing point to hide. If you are evaluating whether to move a real-world asset through Onchain Bridges, you should be able to read this post and know what you are trusting when the asset crosses into a Category C chain, and what will change when CCIP catches up.
The compliance layer is what makes any of this defensible for a regulated issuer. The relay can only route mints that the destination chain will accept, and the destination chain will only accept mints to admitted addresses. That is the same story we tell about EVM. Category C does not weaken it; it just makes the transport layer visible in a way CCIP hides from you when CCIP is there.
Try the demo
The Category C loops are live on testnet: move a token from an EVM source to Stellar, to Stacks, or to Canton, and watch each step from the source vault lock through the DON-attested mint. Every hop is a real transaction on a public chain.
Testnet, unaudited. Not a solicitation. Not an offer of securities. Every transaction you make on this site is signed by your own wallet on a public testnet. No real money moves.
Testnet, unaudited. Not a solicitation. Not an offer of securities. Every transaction you make on this site is signed by your own wallet on a public testnet. No real money moves.