Instantaneous Liquidity Framework SDK

1. Overview¶

AXC’s Instantaneous Liquidity Framework SDK provides a liquidity management layer for tokenised alternative assets. It is designed to support atomic on-chain deposits and withdrawals when sufficient liquidity is available, while accommodating the longer settlement cycles of the underlying investments.

The framework combines three mechanisms:

• Internal netting: Incoming deposits offset withdrawal requests, reducing the need to liquidate underlying assets.

• Liquidity reserves: An issuer-configured allocation provides capital for immediate withdrawals.

• Discounted liquidity: Planned mechanisms allow participating funds or whitelisted liquidity providers to offer immediate settlement at a discount when reserve liquidity is insufficient.

The framework currently applies only to assets distributed on a permissionless basis. Whitelisting liquidity providers is a separate participation control and does not imply that asset transfers are permissioned.

Liquidity limitation: “Instantaneous” describes a supported execution path, not an unconditional liquidity guarantee. Under the described design, immediate settlement depends on available reserves or a funded counterparty willing to execute.

2. Core Concepts¶

3. Component: Liquidity Reserve

• Reserve allocation: Incoming deposits first enter the liquidity management layer before capital is deployed into underlying investments. Issuers can configure an allocation to the liquidity reserve. For example, an issuer may allocate 10% of incoming deposits to the reserve and deploy the remainder according to the product’s investment strategy, after accounting for withdrawal obligations. The 10% allocation is illustrative, not a protocol-wide requirement.

• Custom parameter implementation: A percentage of each incoming deposit. A target percentage of total product assets. A minimum reserve requirement. A combination of these policies.

• Reserve composition: The proposed design permits reserve capital to be held in a separate vault, potentially using instruments such as tokenised Treasury products or on-chain lending positions. Recommended accounting rule: Distinguish total reserve value from liquidity that can actually be withdrawn and delivered during the settlement transaction.

• Reserve replenishment: The reserve is replenished through new deposits available for netting. Proceeds from underlying-asset redemptions or permitted liquidations. Withdrawals from reserve investments, where executable. The allocation of replenished funds between queued obligations, new withdrawals and investment deployment remains an execution-policy decision to be specified.

4. Component: Internal Netting¶

• Internal netting: Uses incoming deposits to meet withdrawal demand before deploying residual capital into the underlying assets.

• Illustrative flow: A depositor supplies the settlement asset. The protocol evaluates eligible withdrawal obligations.Available incoming funds offset those obligations. Remaining funds are allocated between the reserve and underlying investments according to the configured policy. Example**:** If incoming deposits total 100,000 units and eligible withdrawals total 60,000 units, netting can use 60,000 units to satisfy withdrawals, leaving 40,000 units for allocation before fees and other adjustments. This example illustrates cash flow netting only. It does not specify token pricing, issuance quantities or queue priority.

• Implementation requirement: Specify whether netting occurs within individual transactions, through periodic batches or through an external operator.

5. Component: Withdrawal Processing and Redemption Queue¶

• Instantaneous withdrawals are settled against available liquidity: If liquidity is sufficient, the request can follow the immediate-settlement path. If aggregate demand exceeds available capacity, the excess enters the redemption queue. The supplied design does not yet establish whether an individual request can be partially fulfilled. The final implementation must define whether it: Settles the available portion and queues the remainder; or Queues the entire request when full settlement is unavailable.

• Queued withdrawals: Queued requests await replenishment from underlying-asset redemption or other permitted liquidity sources. Queue entry is not completed settlement. Users and integrators must be able to distinguish: A request being accepted. Liquidity becoming available. Payment being completed.

• Queue policies: Priority, FIFO, pro rata or another allocation method. Pricing, NAV or reference price applied at request, approval or settlement. Token handling, Whether tokens are locked, transferred or burned. Partial settlement, Whether a request can settle in multiple portions. Cancellation, Whether and when an unsettled request can be cancelled. Payment, Automatic distribution or a separate claim transaction. Liquidity allocation, Whether queued requests take priority over new immediate withdrawals.

• Product-specific timelines: Standard and instantaneous-withdrawal requests may have different settlement rules. Integrators should refer to the Deposit and Withdrawal Timelines section of the relevant product documentation. The relationship between the standard-withdrawal queue and the instantaneous-withdrawal overflow queue requires confirmation.

6. Planned Component: Dynamic Liquidity Mechanisms¶

AXC is developing additional execution paths for periods when reserve liquidity is insufficient.

The objective is to increase the availability of immediate exits, not to guarantee that every request will find a counterparty.

• Dutch Auction Mechanism: The proposed auction mechanism adjusts the offered exit price over time to attract liquidity providers. A holder accepts a minimum price or maximum discount, and participating counterparties may fill the request within those limits. Parameters to define. Reference price and its freshness requirements.Starting and maximum discount. Discount progression. Auction duration and expiry. Partial-fill rules. Cancellation rights. Settlement asset. The draft links discount progression to the time required to satisfy pending withdrawals. The implementation must clarify whether this means elapsed auction time, estimated redemption time or another measurable input. Design constraint: An auction changes the offered price; settlement still requires a funded participant to accept it.

• Direct Fund Liquidity: Under this proposed mechanism, the underlying fund provides immediate liquidity at a predetermined discount. The implementation must specify whether the transaction is: A fund redemption. A token repurchase. A transfer to a designated fund-controlled liquidity account. These alternatives should not be presented as interchangeable SDK operations. Fund participation, available capacity, pricing and settlement authority must be explicitly configured.

• Whitelisted Liquidity Providers: Whitelisted liquidity providers may supply immediate payment in exchange for asset tokens or eligible redemption claims. Under the proposed model, the provider accepts the waiting period associated with the underlying redemption cycle in exchange for discounted acquisition. This as a potential return opportunity, not guaranteed arbitrage. The transaction’s economics depend on subsequent proceeds, timing and costs. Parameters to define; Provider eligibility and revocation. Quote submission and expiry. Available funding. Minimum user proceeds. Transfer of tokens or redemption rights. Atomic settlement conditions.

7. SDK Responsibilities¶

The following describes the recommended integration surface, not existing method names.

• Execution controls: Applications should obtain explicit user authorisation for: Minimum acceptable proceeds. Maximum permitted discount. Transaction or quote expiry. Partial fulfilment. Queue fallback.