Deterministic addresses
Omnisea uses deterministic deployment so bridge contracts and representation tokens can keep the same address across supported chains.
The bridge contracts, representation implementation, and every representation token can be predicted before deployment. Representation addresses match across chains when the bridge address and OFT implementation address match across chains.
How the guarantee works
The bridge computes each representation address as a deterministic minimal proxy from the OFT implementation address and the asset's typed canonical identity: (originalChainId, originalTokenAddressType, originalToken). That means predictRepresentation(originalChainId, originalTokenAddressType, originalToken) returns the same address on every supported chain where the bridge and OFT implementation were created from the same CREATE3 deployment flow, and that address is correct before the first transfer ever happens.
Indexers, wallets, and UIs can label Omnisea representations of a known original without maintaining a separate address registry per chain.
What this means for integrators
- Hardcode one EVM bridge address per asset kind for every chain. There is no per-chain address registry to maintain.
- Compute a representation address off-chain once; it is valid network-wide.
- A token's representation address can be safely displayed, allowlisted, or used in routing logic before that token has ever been bridged to the chain in question.
- Track the OFT implementation address in deployment artifacts. It is part of the deterministic representation-address formula and should be verified by smoke checks.
See Deployments for the live addresses.