An asset issuer that needs its token on more than one chain has a build-or-buy decision. It can build the cross-chain infrastructure itself, or adopt a standard and configure it. Both paths leave the issuer owning the asset, and they differ in what else it owns.
This page sets out what each path requires, what stays the issuer's responsibility either way, and how to compare them honestly. To work through the decision for a specific asset, reach out to our team.
What is the build-or-buy decision for cross-chain infrastructure?
It is the choice of who writes and operates the machinery that moves a token between chains: the contracts on each chain, the accounting that keeps supply correct, the party that attests a transfer happened, and the delivery of the message on the far side.
Building means the issuer implements and runs those parts. Adopting a standard means the contracts and the verification layer already exist, and the issuer configures them for its own asset. Neither path outsources ownership of the token.
What building requires
Five workstreams, and the last two are the ones teams underestimate.
- Contracts on every chain, plus the accounting that keeps total supply constant as balances move between them.
- A verification mechanism that lets a destination chain accept a claim about a source chain it cannot read.
- Delivery, meaning something that pays destination gas and executes the message on arrival.
- Per-chain differences, including decimal precision, signature schemes, and finality behaviour that varies by network.
- Ongoing operation, including monitoring, recovery when a transfer stalls, and re-verification of assumptions as chains change.
The fourth is the one that expands on contact with real chains. Precision differences alone require converting amounts to a shared representation before sending and reconstructing them on arrival, with the remainder below that precision handled deliberately. It is a small piece of logic that has to be exactly right.
The fifth has no end date. It is the reason multi-chain asset operations is a standing workload rather than a launch task.
What adopting a standard requires
Configuration rather than construction, and the configuration is where the issuer's decisions live.
Under the OFT standard the accounting model, the contracts, and the messaging are already built and audited. What the issuer sets is which verifiers must attest to its messages, how much source finality each pathway waits for, and which controls are enabled. These are the levers worth spending time on, and setting them explicitly is part of adopting the standard, since defaults are placeholders rather than recommendations.
That is the shape of the trade. The accounting, the verification layer, and the per-chain handling arrive already written, and what the issuer keeps is the set of choices specific to its own asset and its own risk appetite.
What each path costs and leaves you owning
The comparison that matters is not upfront effort, it is what remains yours afterwards.
| Build in-house | Adopt a standard | |
|---|---|---|
| Contracts and accounting | You write and audit them | Already written and audited |
| Verification | You design and operate it | You select verifiers per pathway |
| New chain | An engineering project | A deployment plus configuration |
| Per-chain quirks | Yours to discover | Handled by the standard |
| Ongoing operation | Yours | Yours |
| Token ownership and controls | Yours | Yours |
| Integration effort | Bespoke work per venue | Less custom work where the standard is known |
The last row rarely appears in a build estimate, and it is worth stating precisely. What a widely deployed standard changes is how much bespoke work each integration takes, because a venue that already handles the interface has less to build. Listing and integration remain decisions for exchanges, lending protocols, and custodians to make on their own terms, so the standard shortens the path rather than settling the outcome.
How to decide
Four questions, answered honestly about your own team rather than in the abstract.
- How many chains, and how often will that change? Every chain added is a deployment and a pathway to configure, so a footprint you expect to grow is worth planning for from the start.
- How many assets? The build cost is paid once per implementation, and the operating cost is paid per asset per chain.
- Can you staff the operation as well as the build? Monitoring, incident response, and configuration review are permanent roles either way.
- What must you be able to evidence? For a regulated asset, a named verification configuration is a straightforward thing to show a reviewer.
A pattern worth noting is that several of the largest issuers built their own tooling first, largely because they reached multi-chain scale before shared standards existed. That work solved the problem ahead of the industry, and it meant each team independently building the same accounting, verification, and per-chain handling. What a standard offers now is that those layers arrive already built, so engineering time goes to what is particular to the asset.
The difference shows up in the marginal cost. Adding a chain becomes a deployment and a pathway configuration rather than a project, and adding an asset does not multiply the configuration surface when tokens share one messaging channel. Moving value between two chains is tractable to build. Running twelve assets across twenty chains with controls, limits, and an audit trail on each is a different kind of problem, and it is the one a standard is shaped for.
FAQ
Does adopting a standard mean giving up control of the token?
No. The contracts are the issuer's either way, and there are two shapes. A token can implement the standard directly, so the token and its cross-chain logic are one contract the issuer deploys. Or an adapter sits alongside an existing token, using delegated mint and burn rights or an escrow, which leaves the original contract untouched. In both cases the controls are callable by roles the issuer holds.
Why did early issuers build their own?
Because they needed cross-chain distribution before shared standards were widely deployed, so building was the available path. What changes the calculation for a team starting now is that the accounting and verification layers already exist and are audited.
Which cost is easiest to underestimate when building?
Ongoing operation. The contracts are a bounded project, while monitoring, recovery, and configuration review continue for as long as the asset exists.
Can an issuer move from a custom implementation to a standard later?
Sometimes. An existing token can adopt the standard through an adapter without replacing the token or moving holders. Replacing a bespoke cross-chain representation may require a token migration, depending on how the original system was built.
Does adopting a standard remove security decisions?
It moves them from design to configuration. The verification mechanism arrives built, and the issuer chooses which verifiers are required and how much finality each pathway waits for.
Work through the decision
Build or buy comes down to how many chains and assets you expect to run, whether you can staff the operation rather than only the build, and what you need to be able to show a reviewer.
To work through it for a specific asset, reach out to our team, or start at Developers.