OFT representations

When an ERC-20 first arrives on a chain, the local bridge deploys its representation - a minimal token contract that exists only to mirror the original across chains.

NFT representations are coming soon. ONFT behavior below is marked as planned and should not be treated as live deployment documentation.

Properties

• Initialized once, by the bridge. The deterministic minimal proxy is initialized at deployment with metadata carried in the first transfer's payload, read from the original at send time. There is no other initializer path, and the template implementation itself is locked (_disableInitializers).
• Mint and burn are bridge-only. Supply on a chain changes only when the bridge delivers a transfer in (mint) or sends one out (burn). Aggregate representation supply across all chains always equals what is locked on the home chain.
• Standard interfaces. OFT representations behave as ordinary ERC-20s for wallets and DEXes, with ERC-2612 Permit enabled on every representation. No transfer fees or rebasing. NFT representation routes are coming soon.
• Chain-invariant address. A given original's representation has the same address on every EVM chain deployed through the same CREATE3 bridge and deterministic clone flow - computable in advance via predictRepresentation(originalChainId, originalTokenAddressType, originalToken) for ERC-20s (why).

What metadata carries over

Metadata reads use bounded-gas defensive staticcalls. Originals that do not implement an interface—or whose fallback rejects a metadata selector—still bridge with safe empty-string, zero, or 18-decimal defaults.

Ownership follows the original

When a transfer starts from the original chain, the bridge defensively reads the original token's owner(). That owner value is carried in the LayerZero payload and synced into the destination OFT representation.

This happens on deployment and on later original-chain messages. If the original token owner changes, the issuer can propagate that change by sending a small transfer from the original chain or by sending an owner-sync-only message. Direct transferOwnership() and renounceOwnership() calls on the representation are disabled, so representation ownership always follows the canonical original-chain state instead of an Omnisea admin handoff.

If the original has no readable owner, the representation stays bridge-owned internally. In that state, the bridge can still mint, burn, and sync ownership, but it does not get issuer feature powers.

What the owner can do

// OFT representation (ERC-20)
function setContractURI(string calldata contractURI_) external onlyOwner;
function requestFeature(Feature feature) external onlyOwner;
function disableFeature(Feature feature) external onlyOwner;

// ONFT representation (ERC-721) - coming soon
function setContractURI(string calldata contractURI_) external onlyOwner;
function setDefaultRoyalty(address receiver, uint96 royaltyBps) external onlyOwner;
function deleteDefaultRoyalty() external onlyOwner;

The owner cannot mint, burn, or move balances. Those paths are onlyBridge, and the bridge only acts on verified LayerZero messages.

OFT owners can also request optional compliance features:

Authorization is a review step for the Verified Asset Pilot. Omnisea can approve a requested feature, but cannot pause, unpause, blacklist accounts, set a compliance contract, or transfer representation ownership directly.

Disabling a feature is owner-only. Re-enabling it requires a fresh on-chain request and Omnisea authorization. Disabling blacklist support does not clear the stored blacklist mapping.

Compliance behavior

Pausable, Blacklistable, and Compliance are inactive by default.

When Pausable is enabled, the synced owner can pause or unpause the representation. When Blacklistable is enabled, the synced owner can update a local blacklist(address => bool) mapping. The bridge address itself cannot be blacklisted. When Compliance is enabled, the synced owner can set an external compliance contract with:

function isCompliant(address from, address to, uint256 amount) external view returns (bool);

Normal ERC-20 transfers check both from and to. Bridge sends check the local sender before burn, and destination mints check the recipient before mint. The public isBlacklisted(account) view returns local blacklist status and, when a compliance contract is active, a conservative account-status result from isCompliant(account, account, 0).

Reading a representation

// On the representation itself:
address bridge          = representation.bridge();
uint32  originalChainId = representation.originalChainId();
address originalToken   = representation.originalToken();
address owner           = representation.owner();
bool    hasOwner        = representation.hasContractOwner();
bool    pausable        = representation.isPausable();
bool    paused          = representation.paused();
bool    blacklistable   = representation.isBlacklistable();
bool    complianceOn    = representation.isComplianceEnabled();

// Or ask the local bridge (authoritative reverse lookup):
(uint32 chainId, uint8 addressType, bytes32 original, bool exists) = bridge.oftToOriginal(token); // ERC-20
// ERC-721 reverse lookup is coming soon with ONFT routes.

exists == true means the token was deployed by the bridge, and (originalChainId, originalToken) is its canonical identity. UIs should display representations under their original's identity (e.g. "USDC - bridged from Base") rather than as independent tokens.

OFT representations emit Mint(to, amount) / Burn(from, amount) alongside standard ERC-20 transfer events, which makes per-chain supply easy to index. NFT representation events are coming soon with ONFT routes.

What representations are not

• They are not issuer-upgradable - the current OFT extension set is Permit plus feature-gated Pausable, Blacklistable, and Compliance.
• They are not wrapped tokens in the lock-box sense on their own chain: there is no local redemption. Exiting a representation means bridging it (burn) toward any chain, including its home chain (unlock).