Introducing Owner-Synced OFT Controls
Published
Omnisea OFT representations now sync ownership from the original token and support controlled issuer features without giving Omnisea custody-like admin powers over transferred assets.
The goal is simple: an ERC-20 can become omnichain while its operational authority still follows the canonical token owner. Token teams get a path to support real-world controls such as pausing, blacklists, and external compliance checks. Holders get representations that remain tied to the original asset instead of disconnected wrappers.
What changed?
Every Omnisea OFT representation carries canonical identity from the original token: the original chain, the original token address, metadata, decimals, and now an owner value when the original token exposes one.
When a transfer starts from the original chain, Omnisea reads the original token's owner()when available and includes that owner in the LayerZero payload. The destination representation then syncs to that canonical owner.
Permit is also enabled on every OFT representation by default, so wallets and applications can build smoother ERC-20 approval flows around represented assets.
Ownership follows the original
Representation ownership is not an Omnisea admin handoff. It is synced from canonical original-chain messages. That matters because a destination representation should not become a separate governance surface controlled by the bridge operator.
If the original token owner changes, the new owner can be propagated by sending a small original-chain transfer or by using the owner-sync-only message path. Destination OFTs do not allow direct transferOwnership() or renounceOwnership(), so local ownership stays anchored to the original token state instead of drifting chain by chain.
If the original token has no readable owner, the representation stays bridge-owned internally. In that state, the bridge can still mint, burn, and sync ownership through verified messages, but it does not get issuer feature powers.
Controlled features are opt-in
Pausable, Blacklistable, and Compliance support are off by default. The current synced representation owner can request one of these features on-chain. Omnisea can authorize a pending request after review.
Authorization does not give Omnisea the feature. Once a feature is enabled, only the current synced non-bridge owner can use it. The owner can also disable an enabled feature. Turning it on again requires a new request and authorization.
This keeps the feature set practical for controlled tokens while avoiding a design where Omnisea can directly operate issuer controls.
What each control does
Pausable lets the synced owner pause and unpause representation transfers after the feature has been authorized. Before authorization, pause calls revert and the representation reports itself as unpaused.
Blacklistable lets the synced owner maintain a local blacklist mapping. The bridge address itself cannot be blacklisted. Normal ERC-20 transfers check both sender and recipient, bridge sends check the local sender before burn, and destination mints check the recipient before mint.
Compliance lets the synced owner set an external compliance contract with an isCompliant(from, to, amount) check. This gives controlled assets a way to use richer compliance logic without forcing every rule into the OFT contract itself.
What Omnisea cannot do
Omnisea can authorize a requested feature. It cannot pause a representation, unpause it, blacklist an account, set the compliance contract, transfer OFT ownership directly, or change balances outside the verified bridge-mint and bridge-burn paths.
That separation is the core mechanic. The protocol can review whether a representation should be allowed to support a control, while the asset's synced owner remains the only party that can operate that control.
Built for controlled tokens
Some assets should stay simple ERC-20s. Others need operational tools because they represent controlled markets, regulated products, tokenized real-world assets, or issuer-managed networks.
Omnisea now gives those assets a more realistic omnichain path. A token can move across supported OFT routes, keep provenance to the original chain, sync owner authority from the original token, and add compliance controls only when the synced owner requests them and Omnisea authorizes them.
The result is not an issuer-upgradable representation and not an Omnisea-operated compliance wrapper. It is a controlled OFT pattern where ownership, provenance, and optional transfer controls have clear boundaries.
Available now
Owner-synced OFT controls are live for Omnisea ERC-20 representation routes. NFT routes remain coming soon.
Token teams and issuers can use the Verified Asset Pilot to claim official routes, verify asset ownership, and request the representation controls their assets need.