Subscriptions and Redemptions say why each step happens; this guide shows the calls, under the same Tx numbers. Your calls are the operator’s; the price source, the investor’s custodian and the issuer each sign their own steps from their own node, and each such step says what they sign. All of an asset’s orders take the same path. With a live standing consent, they are paid on the ledger, in a payment asset the consent names (such as a tokenized deposit or a stablecoin), with both registries settled in one transaction. An asset may take several payment assets, one consent each, and each order names the one it is paid in. Without a consent, orders are paid off the ledger, and the venue books each against the issuer’s mint or burn. $TOKEN is an operator’s bearer.

​
Subscribe, paid on the ledger

​
Tx 1 · Record the order

A subscription is priced later, at the NAV (forward pricing). A frozen investor, a held fund or a policy limit refuses it here, with the rule. paymentInstrumentId names the payment asset, here TD. It may be left out while the fund takes one. A fund that takes two, such as a tokenized deposit and a stablecoin, refuses an order that names none (payment-instrument-required).
curl

​
Tx 2 · The price source prices the subscription

The price source signs the subscription’s price from its own node: it accepts the subscription’s proposal with the NAV it settles at (LotProposal_Accept), and the subscription reads priced.

​
Tx 3 · Ask for the payment

The first settle call sends the investor the payment request: the units at the subscription’s NAV, rounded up to the payment asset’s decimals. The operation’s result reads orderState: awaiting-payment and the amount.
curl

​
Tx 4 to 6 · The investor pays

In its wallet, the investor’s custodian makes a CIP-112 allocation of the payment asset on that asset’s registry and another for the receipt of the units on the fund’s registry (AllocationFactory_Allocate), then accepts the request (AllocationRequest_Accept). GET /v1/holders/inv-001/allocation-requests lists the requests waiting on it. The subscription’s paymentLeg names the leg the payment allocation carries (lot-td-1-payment), who pays whom and how much, and the allocation once it is made: allocated is true when it is exactly what the venue asks.

​
Tx 7 · Settle

The same call again, under a new key, mints the units and makes the payment in one transaction (order: minted); the subscription reads delivered. Before the investor has answered, it submits nothing and names the allocations it awaits. A settle that is refused leaves its problem on the subscription’s reads, as lastFailure.
curl

​
Subscribe, paid off the ledger

​
Tx 1 and 2 · Record the order, priced

Record the subscription with POST /v1/subscriptions, as above (here lot-1), and the price source prices it. The cash is then wired to the fund’s account, off the ledger. Send the bank’s reference for the wire as paymentReference: the order carries it and its reads echo it.

​
Tx 3 · The investor’s custodian requests the mint

The request is made in the custodian’s wallet and names the subscription in its reference, here mint:lot-1 (AllocationFactory_RequestMint).

​
Tx 4 · The issuer mints, once the cash is in

The issuer accepts the mint request on its DA Registry once its bank confirms the cash (MintRequest_Accept), or rejects it with a reason the investor reads.

​
Tx 5 · Deliver the subscription against that mint

The venue books the subscription against a mint of exactly its units, to its investor, made after the order, and only once. Before the mint is on the ledger, the delivery is refused no-mint.
curl

​
Redeem, paid out on the ledger

​
Tx 1 · Record the claim

The investor must be admitted and hold the units free; a held fund and the fund’s policy (a lock-up, a daily limit) refuse here. An investor can claim its own redemption with its own bearer. The claim names its payment asset as a subscription does.
curl

​
Tx 2 · The price source prices the claim

From its own node, the price source signs this claim’s price as a RedemptionPrice that only it signs. Pricing the claim again corrects it.

​
Tx 3 · Ask for the payout

POST /v1/redemptions/red-td-1:settle sends the payout request, priced at the price source’s price of this claim and rounded down to the payment asset’s decimals. Until the claim is priced, it is refused not-priced.

​
Tx 4 to 6 · The investor answers

As for a subscription, the investor’s custodian answers in its wallet: it sets the units aside on the fund’s registry and readies the payout’s receipt on the payment asset’s registry (CIP-112 allocations), then accepts the request.

​
Tx 7 · Settle

The same call again, under a new key, burns the units and pays the investor from the fund’s treasury account in one transaction (order: redeemed); the claim reads settled. A treasury short of the payment asset is refused treasury-short, and nothing moves.
curl

​
Redeem, paid out off the ledger

​
Tx 1 · Record the claim

Record the claim with POST /v1/redemptions, as above (here red-1).

​
Tx 2 and 3 · The investor asks for the burn; the issuer burns

The investor’s custodian requests the burn in its wallet and names the claim; the request locks the units to the issuer (AllocationFactory_RequestBurn). The issuer accepts it on its DA Registry, which burns them (BurnRequest_Accept).

​
Tx 4 · Settle the claim against that burn

The claim reads settled, and the fund pays the proceeds through its bank, off the ledger. Before the burn, the call is refused not-funded or not-burned.
curl

​
Withdraw or release

Several orders of one strike can settle together, netted: see Dealing cycles. Back to the workflows: Subscriptions · Redemptions