Cross-collateral lets multiple eligible assets support a defined set of obligations. The engineering challenge is to connect their market value with enforceable control, liquidation capacity and settlement timing. This guide develops an illustrative borrowing-base calculation, explains where shared collateral creates contagion and sets out the ledger and validation controls needed to make the policy executable.

Define what shares collateral

A cross-collateral account permits more than one approved asset to support debt or trading exposure within a specified perimeter. That perimeter might be one lending market, a group of products under one account controller or a client-specific facility. Its boundary should be visible in contracts and account records, rather than inferred from a common wallet address.

The benefit is less fragmented capacity: an account does not need a separate collateral deposit for every supported instrument. The cost is shared exposure. A loss in one product can consume assets that support another. An institution therefore needs an explicit choice between shared accounts, isolated accounts and bounded risk groups.

This guide describes illustrative engineering decisions for software developed by FT Inc. It does not represent an offered lending facility or custody service. The related portfolio margin guide covers how positions can be evaluated together; accepting multiple collateral assets does not by itself create portfolio margin.

Make eligibility a structured asset record

For each asset, record its exact chain and contract, supported token behavior, valuation method, permitted liabilities, collateral factor, liquidation threshold and concentration limits. Also identify who can freeze transfers, upgrade the token or change redemption terms. A ticker symbol is insufficient to distinguish a native asset from a bridged representation with different dependencies.

Map the path from collateral to the liability's settlement asset. A liquid exchange market, a redemption process and a negotiated transfer each imply a different time to cash. The policy should specify whether the asset can support intraday obligations, longer-horizon credit or neither.

Receipt tokens require additional care. ERC-4626 distinguishes share conversion functions from withdrawal limits and transaction previews. A share-to-asset conversion is not proof that the underlying can be withdrawn immediately. An adapter should separately evaluate valuation, available redemption and any withdrawal queue or restriction in the particular implementation.

A worked borrowing-base calculation

Assume an illustrative account holds 100 ETH marked at $2,000 and $50,000 of cash collateral. Its policy applies an 80% collateral factor to ETH and 98% to cash. The account has $150,000 of outstanding dollar debt; borrowed proceeds have already left the account. Ignore interest for this single snapshot.

Illustrative eligible collateral value
AssetMarket valueFactorCredit contribution
100 ETH$200,00080%$160,000
Cash collateral$50,00098%$49,000
Total$250,000Asset-specific$209,000

The borrowing base is $209,000, leaving $59,000 before additional limits. Now impose a $140,000 cap on ETH's credit contribution: the permitted base falls to $189,000 and remaining capacity becomes $39,000. A borrower with more ETH would not gain additional capacity once that cap binds.

If ETH falls to $1,500, its discounted contribution becomes $120,000. The base is then $169,000 and capacity $19,000. These are entry-limit calculations. Liquidation must use a separately specified maintenance policy and account for execution costs; a negative borrowing allowance does not independently define the liquidation trigger.

Count common dependencies, not just token names

Ten assets do not necessarily provide ten independent sources of collateral. Several wrappers can depend on one bridge, multiple fund tokens can depend on one redemption agent and a set of stablecoins can share a liquidity venue. Record these dependency groups and consider caps at both asset and group level.

Correlation credit also needs a failure case. Assets that track one underlying in normal conditions can diverge when conversion stops. A design might grant favorable treatment only inside a restricted collateral-and-debt category, with a specific stress for that conversion relationship. Aave's E-mode documentation provides a public example of category-specific collateral parameters and borrowing permissions.

An isolation boundary can limit how a less-established collateral asset exposes the broader system. Aave's isolation-mode documentation illustrates collateral-use and borrowing restrictions. These are useful reference patterns, not specifications for an FT deployment. The correct boundary depends on the client's product and settlement model.

Prevent collateral from being committed twice

Track deposited, eligible, reserved, externally committed and withdrawable amounts separately. A pledged token can remain visible in custody while being unavailable for a second obligation. Pending settlement should have a unique identifier, its exact asset amount and a state that prevents the same collateral from supporting unrelated withdrawals.

Every transition needs an accounting rule. A borrow increases debt and transfers an asset; a repayment reduces debt only by the amount actually received under the supported token semantics; a withdrawal releases only unencumbered collateral after evaluating the resulting account. Interest accrual must be current enough to avoid approving capacity against obsolete debt.

Cross-chain transfers need a pending state until the required evidence of settlement arrives. A source-chain lock and destination-chain mint are not one atomic event. Decide when capacity is removed at the source and granted at the destination, including rollback or recovery rules. Granting full credit on both sides during transit is an accidental credit extension.

Keep solvency and available cash distinct

An account can have positive marked equity while lacking the asset needed to meet an immediate obligation. A tokenized holding redeemable after several business days cannot automatically fund an onchain payment due now. The account needs a usable conversion route or separately committed liquidity under explicit terms.

During liquidation, choose assets and sizes based on the resulting account, not solely on their current market value. Selling a liquid hedge can increase exposure to an illiquid position. Paying an incentive reduces the remaining collateral buffer. Recompute the account after each partial closeout and record residual obligations explicitly.

The liquidation architecture should also state which parties may receive permissioned collateral. A quote from a participant unable to accept the asset is not executable liquidity. For restricted tokens, receiver eligibility and transfer controls belong in both preflight simulation and final settlement checks.

A separate position-reduction study demonstrates the portfolio effect with a synthetic two-leg account. It compares equal close budgets while keeping marks and the risk model fixed.

Validate the policy through adverse transitions

A useful test suite checks more than the displayed borrowing power. Generate portfolios near each cap, vary debt and collateral decimals, accrue interest across long idle periods and reorder deposits, withdrawals, borrows and settlements. Verify that supported transfer behavior matches the ledger's assumptions and reject unsupported token mechanics explicitly.

  • Collateral reserved for one obligation cannot be withdrawn or credited elsewhere.
  • A stale price cannot silently increase borrowing capacity.
  • A cap applies across every account or facility included in its stated scope.
  • An asset suspension blocks the intended actions without erasing ownership records.
  • A partial liquidation charges incentives and preserves an accurate residual debt balance.

Version eligibility rules and test proposed changes against existing accounts. Operators need to know whether a change blocks additional exposure, starts a managed reduction or changes liquidation eligibility. Preserve the old configuration for historical reconstruction. A deployable specification should make each of these effects explicit enough to implement and review.

Common engineering questions

What is cross-collateral in an onchain account?

It is an arrangement in which multiple approved assets support obligations inside a defined account or facility. Each asset can have different valuation rules, limits and liquidation treatment. Assets outside that perimeter do not automatically support its debt.

Why use a haircut and a concentration cap?

A haircut reduces the recognized contribution of an asset. A concentration cap limits how much capacity that asset or dependency group can provide in total. They address different dimensions of the collateral policy and should be calibrated together.

Can tokenized funds be used as collateral?

A software architecture can support eligible tokenized assets, but suitability depends on valuation, control, transfer permissions, redemption timing and executable liquidity. Tokenization alone does not establish immediate availability for closeout.

References & further reading