Security model

Omniassets uses a lock-and-mint, burn-and-unlock model. Its main trust boundaries are the original token, the Omnisea contracts, the configured LayerZero pathway, and the remote Router peer.

Backing

OmniseaVault holds original ERC-20s and records lockedBalance(token). Only the bound Omnisea core can record a lock or release backing.

The owner cannot withdraw recorded backing through the current contracts. Surplus recovery is limited to:

vault token balance - locked balance

On remote chains, only the local core contract can mint or burn an Omniasset.

Message authority

LayerZero DVNs verify the configured message pathway. The destination Router then checks that the payload came from its active peer for the source EID.

This is a trusted-peer bridge model. The destination does not independently prove the remote lock or burn onchain; it treats an authenticated peer payload as authoritative. A compromised peer, incorrect peer configuration, or compromised verification pathway can affect destination representation supply or original-chain backing.

Router peers are write-once. A configured peer cannot be replaced through the current contract. Applications can read peers(eid), peerSetAt(eid), peerActivationTime(eid), and isPeerActive(eid).

Contract mutability

The core, Router, Registry, Vault, Fees Manager, and Omniasset implementation are non-upgradeable. Changing their executable code requires a new deployment.

Owners still control operational values such as protocol fees, fee receivers, Router gas floors, the LayerZero delegate, and initial peer configuration. These values are readable onchain and should be monitored by production integrations.

Failed messages

A trusted transfer that fails during destination execution is cached instead of blocking the message channel. Anyone can retry it or pay to restore it to the original sender. GUID consumption prevents the same message from settling twice.

Recovery is permissionless, but it does not make every failure recoverable immediately. A token pause, blacklist, insufficient backing, or incompatible token behavior may need to be resolved before retry or restore can succeed.

Original-token risk

The bridge inherits behavior from each original ERC-20:

• fee-on-transfer tokens are measured by Vault balance change when locked;
• rebasing or reflection can change Vault balances after a lock;
• pausable, blacklistable, or admin-controlled tokens can block an unlock;
• unusual metadata implementations can prevent the first representation deployment.

Balance-delta accounting supports transfer fees at entry, but it cannot remove later issuer or token-contract risk. Review the original token before treating its Omniasset as equivalent to a standard ERC-20.

Omniasset controls

An Omniasset can mirror ownership from an original contract that exposes owner(). Optional pausing, blacklisting, and compliance features require an explicit request and bridge authorization before that owner can use them.

Clients should still handle ERC-20 transfer reverts. A representation with enabled restrictions can reject transfers, mints, burns, or recovery settlement according to its current state.