Onchain prime brokerage architecture

Start with the account and its obligations

A shared trading interface does not create a shared risk system. If a lending module, derivatives venue and settlement adapter each calculate available collateral independently, the same deposit can appear available several times. The central design problem is an authoritative account ledger: ownership, assets, debts, accrued fees, unsettled trades, reservations and permissions must have one defined meaning across every module.

A proposed partner instance can separate the account into risk domains. Approved exposures may share collateral inside one domain; an unfamiliar token, issuer or settlement process can remain in a dedicated subaccount. The boundary must be enforced when collateral moves, orders execute, debt accrues and positions are liquidated. Naming a subaccount in an API is insufficient if another module can withdraw its supporting assets.

Define the account's unit of value and its valuation timestamp. A dashboard that combines a fresh token balance with yesterday's issuer valuation and an unconfirmed repayment needs to disclose those differences to the risk engine, not hide them in a single available-balance number.

Give each module a narrow contract with the ledger

The ledger should accept explicit state transitions rather than let every integration write arbitrary balances. A lending module creates or repays a debt claim. An execution module exchanges specified assets under a bounded authorization. A derivatives module updates position exposure and settlement obligations. A redemption adapter records that collateral has entered an asynchronous process and is no longer freely withdrawable.

Every successful transition should leave the account in a permitted state. Intermediate states inside a transaction still matter because token callbacks or external adapters may observe them. Keep the settlement coordinator small enough that reviewers can trace value and authority across the complete operation.

Collateral reuse requires reservation accounting

Collateral reuse means that one pool of eligible equity can support several approved exposures after aggregate risk is assessed. It does not mean each product receives an independent credit allowance against the entire deposit. A limit order, pending withdrawal and accepted redemption request can all create claims on assets that still appear in the wallet.

One design is to reserve the maximum authorized consumption when an operation becomes binding, then release unused capacity after settlement or expiry. Another is to perform authoritative checks only at execution, while treating displayed capacity as indicative. The latter reduces reservation complexity but accepts more failed fills. A system can combine these approaches if the distinction is explicit to integrators.

Risk offsets also need scope. A spot holding and a short derivative may offset directional price exposure while retaining funding, basis, counterparty and settlement risks. Cross-chain assets need separate treatment when their movement depends on a bridge. A consolidated user interface cannot make separated settlement domains atomic.

Trace the whole execution and settlement lifecycle

Consider a hypothetical account requesting leveraged exposure through a solver. The account specifies its maximum contribution, maximum debt, minimum received position, expiry and fee limit. The solver supplies a quote. Settlement validates the authorization, receives the required assets, books the debt and resulting collateral, pays the solver, and checks the final account state. If a required leg fails, the transaction must not leave an unauthorized residual position.

Signed requests can use EIP-712 structured data, but replay protection remains an application responsibility. The architecture still needs consumed nonces, cancellation rules and a domain bound to the intended deployment.

For offchain issuer redemption, replace the assumption of atomic completion with explicit states: reserved, submitted, acknowledged, funded, reconciled and closed. A submitted request is not settled cash. Each transition needs evidence, an authorized actor and a recovery path when a response arrives late or twice.

Separate operating authority from software authority

A partner deployment needs a responsibility map as concrete as its contract diagram. Identify who selects assets, approves credit limits, controls custody accounts, operates solvers, supplies valuations, changes emergency settings and reconciles exceptions. FT Inc's engineering scope can include contracts, risk logic and integration support. The client and its appointed providers determine and perform the relevant operating and regulated functions.

Software roles should reflect this separation. An adapter operator may confirm receipt of a redemption acknowledgment without permission to raise collateral values. A risk operator may lower a borrowing cap without authority to transfer assets. Governance should distinguish routine parameter changes from upgrades that alter withdrawal rights or loss allocation. OpenZeppelin's access-control documentation describes role and delay mechanisms that can help implement these boundaries; the actual authority model must be specified for the deployment.

Emergency controls need a documented effect on repayment, withdrawals and liquidation. A broad pause that traps every recovery action can worsen an incident.

The institutional deployment guide maps these boundaries across the issuer, asset controller, financing party and engineering team.

Design containment before adding products

Shared infrastructure creates useful coordination and a larger common failure surface. If every product relies on one oracle router, one corrupted feed may affect borrowing, withdrawals and liquidation together. If settlement and lending share one cash pool, an issuer delay can reduce liquidity available to unrelated borrowers. Model these dependencies explicitly.

Useful controls include asset and issuer caps, debt-asset limits, bounded adapter permissions, concentration thresholds and staged product activation. Distinguish a loss from a delay: an overdue receivable may require reduced credit recognition and additional liquidity even before a final shortfall is known. Repeatedly extending a due date should not reset the incident clock.

For chain events, distinguish transaction submission, inclusion and the required finality level. Ethereum's finality documentation explains why inclusion and finality are different states. An external payout policy must decide how much chain-reorganization exposure it accepts before releasing irreversible cash.

Validate the joined system, then expand its scope

Testing each module separately cannot establish that the combined account conserves value. Build scenarios that cross boundaries: borrow, trade, accrue funding, request withdrawal, enter liquidation and receive a delayed settlement callback. Check that asset reservations never disappear, obligations remain counted, and replayed events cannot produce a second payout.

Reconciliation should compare contract balances, account claims, debt records, reserved collateral and external confirmations at a defined checkpoint. When they disagree, the system needs an exception state and an owner. An unexplained difference is not resolved by making the dashboard match the chain balance.

A proposed first deployment should minimize simultaneous unknowns: a small eligible asset set, one settlement asset, a bounded solver set and hard exposure limits. Expansion should follow evidence about fill reliability, settlement delays, liquidation capacity and recovery procedures. The architecture is successful when operators can explain both a normal transaction and the most expensive plausible failure using the same ledger and control model.

Common engineering questions