Neither Omnisea nor an issuer can withdraw the tokens backing an Omniasset. Our LayerZero 3-of-5 DVN configuration is frozen, and contracts cannot be upgraded.
Once a router peer is registered, neither Omnisea nor the issuer can replace it. A compromised issuer wallet cannot point the asset to another sender.
Each route requires 3 of 5 configured verifiers. These settings are frozen before transfers are enabled and cannot be changed afterwards. No LayerZero delegate is appointed.
Without an issuer compliance contract, your asset starts with the active chains available at creation. With issuer compliance, you enable each destination explicitly. If Omnisea adds another chain later, it stays disabled for your existing asset until you enable it. This is precisely the mechanism that distributes authority between the protocol, which adds new chains, and the issuer, who approves them.
HOW OMNISEA OFTs DIFFER
Omniassets use the standard LayerZero OFT interface. The difference is in who can change what: peers are permanent, verification is frozen and issuers cannot mint cross-chain supply at will. These restrictions are enforced by the contracts.
If an OFT owner can change its trusted peer, a compromised owner key can point the token to a malicious sender. Omnisea removes that power: once a peer is registered, it cannot be replaced.
An issuer can change fees within protocol limits, claim its fees, enable supported chains and update its compliance contract if one was configured. It cannot change peers, change frozen verification or mint Omniassets directly. Admin rights over the original token are unaffected.
Non-custodial does not mean risk-free. Transfers still depend on the contracts, supported chains, LayerZero verification and the original token. Frozen settings also mean failed verifiers cannot simply be replaced. Because Omniassets share infrastructure, a protocol-level bug could affect more than one asset.
FAILED TRANSFERS
If the router records a failed cross-chain transfer, it can be retried or returned to the original sender. Its status stays visible on the asset page. Recovery still depends on the chains, verification and contracts being operational.
Once the problem is resolved, anyone can retry the failed transfer. The original recipient and transfer details cannot be changed.
For the first 7 days, the designated restorer can return a failed transfer. After that, anyone can trigger the return. Funds always go back to the original sender. The return requires a new cross-chain message and its fee.
See when the source transaction is confirmed, when the destination message is delivered, and whether a retry or return is in progress.