Security model

Current admin model

The EVM Omniasset system is split into a non-upgradeable entrypoint, Router, Registry, Vault, and Fees Manager. Omnisea coordinates accounting. OmniseaRouter is the only LayerZero OApp. OmniseaVault holds canonical backing, while OmniseaRegistry freezes origin identity and deploys deterministic minimal-proxy representations.

The bridge owner still controls operational configuration:

• one-time Router peer setup
• LayerZero delegate setup
• one-time endpoint-to-chain mapping for canonical owner sync
• fee values and fee receivers
• issuer fee attribution for the Verified Asset Pilot
• authorization of OFT features already requested by the current synced OFT owner

Feature authorization is not feature use. Omnisea can approve a pending Pausable, Blacklistable, or Compliance request, but only the current synced OFT owner can pause/unpause, update the blacklist, set the compliance contract, or disable an enabled feature.

What the owner can and cannot do

The bridge owner controls operational configuration in the currently deployed implementation. It is not the owner of issuer OFT representations once ownership is synced from the original chain.

Fee withdrawal functions operate on fee accounting (collectedProtocolFees, collectedFeeTokenProtocolFees, collectedIssuerProtocolFees, and collectedIssuerFeeTokenProtocolFees), which is tracked separately from locked token balances. Accidental-token recovery on the Fees Manager also excludes every unpaid protocol and issuer liability.

Omnilink trust boundary

Omnilink is separate from token escrow and representation supply. It transports approved source-chain view results and cannot use a read to mutate the target because every configured path executes through staticcall.

The Omnilink owner can:

• Register or disable exact (target, callData) source paths and choose their staticcall gas/result-size bounds.
• Attach an optional source-side validator.
• Configure each peer once, enable or disable a route, and pause inbound or outbound reads.
• Set the native flat fee up to its immutable cap and change the fee receiver.
• Configure the OMNI token once when its address is available.

The owner cannot make an unregistered path permissionlessly relayable, replace an existing peer, replace the configured OMNI token, recover OMNI backing outstanding rewards, or recover native balance reserved as collected protocol fees.

Destination Omnilink instances trust authenticated messages from their configured source peers. They validate the source chain mapping, recompute the deterministic read ID, bound result and message sizes, reject duplicate GUIDs, and ignore sequences older than the latest stored result. An ignored stale sequence cannot consume a newly locked OMNI reward. These checks prove the path and ordering of the relayed bytes; they do not prove that the underlying feed, vault, or protocol value is economically correct.

Consumers remain responsible for expected target/calldata identity, result schema and configHash, source freshness, embedded feed timestamps, units, decimals, deviation limits, market-hours policy, and manipulation risk. Typed price, NAV, and ERC-4626 adapters make these semantics explicit and use immutable source registrations, but aggregation does not turn convertToAssets or a single feed into an independent oracle.

OMNI requests are local bounties, not cross-chain commands. A requester can cancel after one hour while an unrelated source result is still in flight. A late result remains valid but receives no reward, so relayers must price this cancellation race themselves. Read Omnilink reads for the full flow.

Omnibook owner controls

Each Omnibook is a separate chain-local contract from the bridge. It holds maker escrow for open orders and collected quote-token taker fees in separate accounting paths.

Only the maker can cancel a live order. Anyone can clear an expired order, but remaining escrow always returns to the maker.

Omnibook Fill Hook recovery

The Omnibook Fill Hook is a separate destination composer for bridge-and-fill buy orders. Only the LayerZero endpoint can invoke its lzCompose entrypoint, and the authenticated _from value must be the local Omnisea Router.

For each delivery, the main bridge message first credits the representation to the composer. The composer then approves Omnibook for the exact amount, attempts the fill, and clears the allowance. It also enforces the seller's minQuoteProceeds before forwarding quote-token proceeds.

If the fill fails, the hook clears the allowance and attempts to return the delivered representation to the source-chain sender on the settlement chain. If that transfer fails, it records a pending refund that only the beneficiary can claim. The owner can withdraw accidental ERC-20 balances, but cannot withdraw amounts tracked by pendingRefundLiability.

Morpho borrow composer boundary

OmniMorphoBorrowComposer is a separate Base contract from Omnisea and Morpho. It receives an already credited Omniasset through lzCompose, supplies it to Morpho on behalf of the authenticated source sender, deducts a bounded success fee, and sends the remaining borrowed Base USDC to the request's receiver.

Authentication and position ownership

Only the Base LayerZero endpoint can call the inherited lzCompose entrypoint, and the authenticated _from value must equal the immutable local Omnisea Router. The versioned compose envelope binds the GUID, sender, origin identity, local token, recipient, amount, and application message.

The composer requires the envelope recipient to be itself. Its authenticated source sender becomes the Morpho onBehalf account, so the resulting collateral and debt belong to the user rather than the composer.

The composer is permissionless at the market layer. A request can name any existing Base Morpho market whose collateral token exactly matches the arriving representation and whose loan token is the composer's immutable Base USDC. Omnisea's web registry is the verification boundary for the two reviewed BNB Core configurations.

Authorization and atomicity

The user either preauthorizes the composer in Morpho or signs sequential temporary enable and revoke authorizations. Temporary authorization, collateral approval, supply, borrow, post-borrow maximum-LTV enforcement, and revocation run in one external self-call.

If any step fails, Solidity atomicity unwinds the Morpho position change, fee transfer, and token approval before the outer compose callback handles the refund. The composer also validates the request deadline, market existence, nonzero oracle price, exact borrowed assets, and maxLtv < lltv.

The owner can set the successful-borrow fee and its recipient, but the fee has an immutable 20 bps ceiling. Every request binds maxFeeBps; a higher fee at execution causes a refund, while a lower fee benefits the borrower. No success fee is charged on failed requests.

Refund isolation

The normal failure outcome is the destination representation on Base, not the original token on BNB Chain. The composer first attempts a direct refund to the selected recipient. If the token transfer fails, it records one pending refund by GUID:

• pendingRefunds[guid] binds one token, beneficiary, and amount;
• pendingRefundLiability[beneficiary][token] keeps different users' claims separate;
• totalPendingRefundLiability[token] protects the aggregate reserved balance;
• only the recorded beneficiary can claim, although that beneficiary may choose another recipient.

Duplicate GUIDs cannot repeat a successful borrow or refund. A new delivery cannot use token balance already reserved for earlier pending refunds.

Owner powers

The Base Safe owns the composer. It can recover accidental ERC-20 balances only up to:

balanceOf(composer) - totalPendingRefundLiability[token]

It cannot withdraw any balance reserved for recorded user refunds. The owner can recover native value because the current one-way borrow composer has no native user liability. The contract is non-upgradeable; changing its immutable endpoint, Router, Morpho, or USDC dependency requires a new deployment.

Trusted peer authority

LayerZero DVNs verify that a message came from the configured source pathway. They do not independently prove that the remote bridge burned or locked assets correctly. Once a peer is active for an endpoint ID, the local bridge treats that peer's payload as authoritative.

For ERC-20 transfers, this means:

• A trusted peer message whose originalChainId equals the local chain and whose original token is a local ERC-20 can unlock the bridge's escrowed balance for that token.
• A trusted peer message for a non-local original can mint or deploy the local representation.
• A compromised remote bridge, bad peer configuration, or compromised pathway can therefore affect local escrow and representation supply.

This is the normal trusted-peer bridge model, not an on-chain proof-of-burn model. The mitigation is operational: immutable peer setup, CREATE3 same-address deployment, LayerZero pathway hardening, multisig ownership, and independent monitoring.

Peer setup is one-way

The single most sensitive owner power - pointing the bridge at a remote peer - is constrained on-chain:

• setPeer can initialize an unset endpoint ID with a nonzero peer. After that, the same peer is a no-op, while clearing it or replacing it with a different peer reverts.
• A first-time peer at the bridge's own CREATE3 address (the only legitimate Omnisea deployment on any chain) becomes trusted immediately.
• A first-time peer at any other address only becomes trusted after a 7-day activation delay (endpointActivationTime = 7 days). Until then isTrustedPeer is false and its messages are rejected.

Anyone can verify this live on either bridge: peers(eid) returns the configured peer, peerSetAt(eid) records when it was first set, peerActivationTime(eid) returns when it activates, and isPeerActive(eid) tells you whether the route is currently trusted. A compromised owner key cannot redirect an already configured message channel. For new unset routes, any non-CREATE3 peer still has a 7-day public activation window.

Message verification (LayerZero V2)

Every transfer is a LayerZero V2 message:

• Peers. Each bridge only accepts messages whose sender is the configured and active peer for the source endpoint ID. Peers are immutable once set. Same-address CREATE3 peers are active immediately; first-time peers at different addresses enter a 7-day activation delay before they are trusted. Anything else reverts with InvalidPeer.
• Verification stack. Each message must satisfy the effective LayerZero Endpoint send/receive-library and DVN configuration before it becomes executable. All 56 Omnisea directions have verified Router identity, chain mapping, worker support, and live quotes. The 42 directions that do not involve Robinhood Chain inherit LayerZero defaults. The 14 Robinhood directions explicitly require LayerZero Labs and Nethermind; both DVNs must attest.
• Executor. The LayerZero executor delivers the message with the gas the sender purchased via options. Execution gas floors (minTransferGas, minCreationGas) are enforced at send time and restore time so messages cannot be sent with unexecutable gas.
• Endpoint-only entry. Router lzReceive is callable only by the LayerZero endpoint (onlyEndpoint), and allowInitializePath only admits active trusted peers. Only the bound Router can deliver a payload to the core.

Failure containment

Destination-side execution failures do not strand the LayerZero channel:

• Endpoint, inactive/untrusted peer, and payload-decode failures revert outright (and are surfaced by LayerZero's own retry machinery). If a message arrives during a peer activation delay, it is not cached in failedMessages; LayerZero can retry it after the peer becomes active.
• Trusted transfer messages that fail during execution (e.g. insufficient destination gas, representation mint failure, compliance rejection, or an exotic token edge case) are cached as failedMessages(guid) and emit MessageFailed. Anyone can retry or restore them after the underlying issue is fixed - there is no admin gate on recovery.
• Restore messages that fail on the source are intentionally not cached, preserving LayerZero's native retry and preventing restore loops.
• Optional application execution uses LayerZero lzCompose. The bridge credit is final before the composer runs, so a failed composer can be retried without repeating the mint or unlock.

Reentrancy and token edge cases

• All send paths and recovery paths are nonReentrant.
• ERC-20 locking measures balance deltas, so fee-on-transfer tokens credit what actually arrived; zero-delta transfers revert with InvalidAmount.
• Rebasing, reflection, blacklist, pausable, or admin-blocked source tokens remain risky as originals. Balance-delta accounting does not protect against later supply/balance mutations or outbound transfers that an external token admin can block, so these assets can redeem less than expected or fail during retry/restore. Separately, OFT representations can enable issuer-controlled Pausable, Blacklistable, or Compliance features only through the request/authorize flow described in Representations.
• Token metadata reads (name, symbol, decimals, contractURI, owner) are defensive. Decimals fall back to 18, while missing text metadata remains visibly empty rather than being guessed.

Audit status