Assetra. Keeping the owner in the register when assets enter DeFi

Our work

We developed the asset-register and servicing modules for Assetra on Cosmos SDK. The work covered ownership attribution inside DeFi contracts, eligibility controls, lifecycle attestations, coupon distributions and the Ethereum mirror.

A regulated token can check who receives it and still lose sight of who holds its economic rights. Once the token enters a pool, the register may show the pool's address while an unrestricted LP token passes exposure to other investors. Coupons then arrive at a contract instead of the people entitled to them. Assetra addresses this at the ledger level, where balances, custody positions, derived shares and eligibility rules share one state machine.

The architecture adds two related controls. Signed reports from administrators, custodians, paying agents and trustees determine what an asset may do as its real-world condition changes. An Ethereum mirror extends the same register through verified cross-chain messages and reconciled transfer history. We connected contract and cross-chain movements to the same ownership register, restrictions and distribution accounting.

The ledger had to own the balance changes

Adding another compliance check to a token would not give Assetra control over an unrelated pool's share token or a router's intermediate movements. The design places regulated balances in a dedicated Cosmos SDK module, x/rwa. Each asset exposes an ERC-20 facade through a stateful precompile, so EVM calls reach the native ledger rather than a second balance table in Solidity storage. Native messages, corporate actions and settlement operations use the same policy-controlled movement path.

Assetra reuses Cosmos SDK, CometBFT, Cosmos EVM and IBC core. It does not introduce a new consensus protocol or virtual machine. The custom modules provide the asset register, identity attestations, lifecycle rules, custody accounting and Ethereum mirror. SDK block hooks and transaction-end checks supply the enforcement points that a token deployed on a general-purpose chain would lack. Regulated assets also stay outside ordinary bank-module transfer paths, preventing those paths from bypassing their policy engine.

This choice preserves Ethereum tooling while making custody integration explicit. A contract cannot receive regulated units until it registers an attribution mode. Existing Solidity syntax does not make every unmodified DeFi contract suitable for these assets. Each integration declares its balance mode: segregated positions, pooled assets or transient routing balances. That narrower contract interface gives the ledger something it can enforce.

Look-through ownership covers three custody behaviours

An escrow or isolated-collateral lending market uses segregated custody. The ledger records positions by asset, contract and owner. Releasing a position names the owner and recipient, so the policy engine evaluates their relationship even though the tokens remain under contract custody. A plain transfer from the escrow without an owner fails. Reassigning a position inside the same contract is also a transfer between owners for policy purposes.

An AMM or pooled vault uses regulated derived shares. Registration creates a share asset in x/rwa, with balances and supply maintained by the ledger. Its policy combines the policies of the pool's underlying regulated assets. Acquiring those shares therefore requires the same relevant eligibility as acquiring exposure directly. A pool cannot substitute an unrestricted LP token and use it as the recognised ownership record. Its code determines pricing, while the ledger controls regulated shares and underlying movements.

Routers use transit custody. The ledger carries the source through intermediate hops, evaluating the eventual movement as if it went from the original owner or pool to the final recipient. The transit-mode check requires zero regulated balance and an empty transit stack at transaction completion. It never becomes a holder merely because units passed through it. This allows a multi-hop route without treating each intermediate address as a new investor.

After execution, an SDK PostHandler checks every touched custody relationship. The PostHandler compares segregated position totals with the contract balance, reconciles pooled shares and checks for nonzero transit balances. Failure discards the transaction's state changes. Nested custody is limited to three levels, with cycles and deeper paths rejected. The limit bounds policy composition and ownership traversal rather than promising unrestricted nesting at constant cost.

Holder limits follow owners, including LP holders

An owner reference connects an investor's attested accounts without publishing their name or documents. The register counts that reference across direct balances, segregated positions and derived shares. Three accounts belonging to one owner therefore do not consume three holder slots. Conversely, holding a pool share cannot hide a new investor behind the pool's existing address.

Pool counting is deliberately conservative. A share holder counts toward each regulated asset the pool is registered to hold, even when the pool's current balance of one asset temporarily reaches zero. A swap cannot release a holder slot and then require it again on the next trade. The counter changes when the owner's relevant reference count crosses between zero and nonzero, keeping the cap tied to recognised ownership relationships.

This remains a transparent ledger. Account activity, eligibility classes and shared owner references are visible on-chain, although identity documents remain with onboarding providers. Look-through establishes attribution within the platform's attestation and custody model. It does not independently discover hidden legal beneficiaries behind false attestations or replace the obligations of an admitted nominee custodian.

Coupons reach investors, bypassing pool pricing

Assetra uses cumulative distribution indexes with checkpoints for direct balances and segregated positions. At the published record time, the block hook advances the index before processing transactions in that block. A later balance change first accrues the income earned under the earlier balance. This separates an already recorded entitlement from ownership acquired afterward.

Pools receive pass-through accounting rather than cash credited to the pool itself. The module converts the underlying entitlement into income per derived share and advances the pool's own checkpoint without paying it. Share holders accrue on their regulated share balances. Nested pools are processed in dependency order. Work at the record point depends on the number of pools, not the number of investors, and the architecture caps pooled registrations per asset to keep that work bounded.

For example, consider a note with a 2.60% coupon for the period. The figures below are illustrative entitlements, not payments from a reported live issuance.

The pool holds three million note units, so its underlying entitlement is 78,000 USDC. Investors owning 60% and 40% of its shares receive 46,800 and 31,200 respectively. The AMM's trading reserves are not increased by that coupon, and its code does not need to forward it. Claims still require the paying agent to fund the relevant distribution escrow. Recorded entitlement does not imply that external cash has already arrived.

Reports update the asset's operating permissions

A reserve shortfall or missed payment matters only if it changes what applications can do. Assetra registers an attestation profile for each asset, including required report types, authorised signers, thresholds, deadlines and acceptance bands. A report identifies the asset, sequence, as-of time, values and source-document hash. x/lifecycle verifies those fields and applies the registered transition. The administrator supplies NAV, the custodian reports holdings, the paying agent reports payments and the trustee reports relevant events.

The resulting state is shared by every ledger operation. An asset can move through payment due, grace, default and redemption states, with guarded and suspended flags removing additional permissions. A reserve shortfall blocks new issuance. A stale dealing NAV leaves subscriptions queued. A missed contractual coupon enters grace and then default under the recorded schedule, while an unfunded discretionary fund distribution produces a guarded state instead. The distinction follows the asset's declared obligations.

Out-of-band values receive asymmetric treatment. The restrictive response applies immediately, but a new dealing NAV or coverage figure waits for the required second confirmation. A single faulty signer can therefore restrict activity without automatically setting a new price at which money moves. Signed reports identify responsibility and make transitions replayable. They do not themselves prove the truth of a custodian's statement or fund valuation.

Deadlines sit in a time-ordered queue processed by BeginBlock, so a missing report does not require a keeper transaction to trigger a response. The implementation processes up to 2,000 deadlines per block and carries overflow forward. Once a transition is applied, subsequent operations use the changed consensus state. That is the precise scope of immediate enforcement; it is not an unbounded promise that every scheduled item or remote network updates simultaneously.

Contract callbacks are notifications, not the safety boundary. They run under gas limits and can fail or continue in a later block without undoing the lifecycle transition. The ledger's permission checks already prevent disallowed issuance, pool entry or collateral use. A pool cannot ignore a default by refusing its callback. At the same time, asset terms can preserve exits and claims instead of freezing all activity indiscriminately.

Ethereum mirrors the register, not independent issuance

Moving units to Ethereum locks them in Assetra's mirror escrow. A proven IBC v2 packet authorises minting the corresponding amount in AssetraMirror. Ethereum verifies Assetra headers and packet evidence through an SP1-based Tendermint light client, while Assetra verifies finalized Ethereum state through its Ethereum light client. Relayers deliver proofs and packets but do not acquire minting authority through a multisignature bridge key.

This shifts the trust boundary to consensus, light-client correctness, proof verification and application contracts. It does not remove it. Assetra's validator safety assumptions still matter to the Ethereum representation. The design applies hourly and total mirroring caps, and regulated assets cannot leave through a generic transfer channel that would omit the register protocol.

An Ethereum holder first links its address to an attested Assetra account using signatures on both sides. The mirror checks sender and recipient status, expiry, owner reference and the asset's compiled policy against an eligibility cache. Only unlocked units cross, simplifying the remote policy model. Holder-capped assets use allocated owner-slot quotas so Ethereum cannot independently create an unlimited number of holders. These constraints define the supported mirror behaviour rather than granting arbitrary Ethereum contracts unrestricted access.

One register still needs explicit sync boundaries

Every Ethereum transfer extends an on-chain hash chain. Periodic reports carry its head, transfer count, supply and block range back to Assetra under Ethereum light-client proof. The register service fetches events for that range, replays the hash chain and accepts the resulting balances only when they match. An archive node returning incomplete history cannot silently change the register because its replay fails the committed head.

The consolidated register therefore identifies Ethereum holdings as of the last reconciled epoch. It is one register of record, not an instantaneous distributed database. Supply reconciliation accounts for escrow and in-flight mint and burn messages. A mismatch triggers the guarded state. Returning units burns the mirror and releases escrow through Assetra's policy path, with error acknowledgements restoring the sender's mirror tokens if the release cannot proceed.

State changes travel in versioned packets, with hourly heartbeats bounding cache freshness. If the last state packet becomes more than 60 minutes old, ordinary Ethereum transfers stop. An issuer-controlled 2-of-3 Safe can freeze or pause locally as a restrictive fast path, but cannot use that path to unfreeze or mint. Relaxation arrives from Assetra. This distinction preserves the light-client minting model while allowing a faster stop during message delays.

Cross-chain coupons need a controlled record window

A shared coupon date would be ambiguous if units could remain in transit at the cutoff. The distribution declaration reaches Ethereum in advance, and mirror crossings close 60 minutes before the record time. Packet timeouts are shorter than that window. Funding calculations and refund handling then account explicitly for messages that completed or timed out. The purpose is to give each unit one entitlement location rather than pay it once on each chain or omit it from both.

Ethereum applies its distribution index lazily at the first transfer or claim after the record time, before changing that balance. Assetra sends the proven total entitlement, and the paying agent funds the Ethereum distributor separately. Claims open only after sufficient funding and the pay time. The funding acknowledgement returns to Assetra so the asset's payment state includes both sides. The register coordinates ownership and obligation accounting; the protocol does not assume cash automatically moves between networks with the entitlement message.

One register across transfers, custody and distributions

We connected balance changes, custody attribution and lifecycle permissions through the same ledger. The controls apply at the paths that can change ownership or create a payment obligation.

• Regulated balance changes invoke the same policy engine.
• Custody checks reject transactions that leave units unattributed or route shares outside the ledger.
• Owner-based holder caps include direct, pooled and nested holdings.
• Recorded deadlines and reports determine lifecycle permissions.
• Restrictive state changes remain independent of callback success.
• Mirror accounting tracks retries, timeouts and delivery order against supply and distribution entitlements.

The important boundary is the movement of rights. An LP transfer goes through eligibility checks, and a delayed mirror message remains attached to its supply and coupon records. The register retains the information needed to reconcile both operations instead of treating each contract or network as a separate ownership history.

Assetra keeps ownership, eligibility and income rights attached to an asset as it moves through contracts and networks. Ledger-owned attribution closes the contract boundary, signed lifecycle reports change enforceable permissions, and verified mirror history extends the register to Ethereum with explicit synchronization limits.