Router and limit orders
Compose Soroban operations and settle limit orders safely.
The Router composes Core and peripheral calls into one atomic command batch. The Limit Order Engine (LOE) settles maker-authorized PT and YT orders, optionally tokenizing or redeeming through Core during the fill.
Router balance semantics
Commands accept either an exact amount or a balance sentinel. The balance sentinel reads the contract's current absolute token balance, not the delta produced earlier in the batch.
Router balances are shared and have no per-user ownership ledger. Do not pre-fund the Router or rely on an absolute balance assertion as proof of transaction-local output; sweep intended residuals within the same batch.
Nested token movements and calls to the broker or bridge require Router pre-authorization. Use the command schema from the exact deployed Router version because peripheral client interfaces can change independently.
Order schema
An LOE order contains:
- Salt, expiry, direction, PT, maker, and receiver.
- Making amount and maker-defined implied APY.
- IBT-leg denomination and wrapper conversion safeguards.
Supported directions are IBT for PT, PT for IBT, IBT for YT, and YT for IBT. Registration requires a valid registered PT, positive amount and rate, an expiry before PT maturity, and supported wrapper behavior where conversion is required.
IBT-leg settlement
maker_token_type selects how the maker funds or receives the IBT leg:
| Value | Settlement behavior |
|---|---|
Ibt | Transfer the PT market's canonical IBT directly, with no conversion. |
Underlying | Deposit underlying into the IBT on funding-side orders, or redeem IBT to underlying on payout-side orders. |
VaultShare | Wrap vault shares into IBT on funding-side orders, or unwrap IBT to vault shares on payout-side orders. |
Underlying and VaultShare require the IBT to expose the corresponding vault or wrapper operations. The conversion and its output floor are enforced inside the same atomic fill.
Authorization and identity
Soroban authorization entries replace EIP-712 signatures. A maker signs authorization for register_order or a batch registration call, and a relayer can attach that authorization when registering and filling. The maker separately approves the LOE for the making token.
The order ID is sha256(XDR(order)). Use (chain ID, order hash) as the external identifier. Authorization-entry ledger expiry and the order's wall-clock expiry are separate values and both must remain valid for the intended workflow.
Pricing and settlement
The engine prices PT from a zero-coupon curve:
PT value = future PT value / (1 + implied APY)^(time to maturity / one year)
YT value = future PT value - PT valueA fill reserves the available amount, pulls maker funds, converts underlying or vault shares when required, enforces order bounds, tokenizes or redeems through PT, pays makers and fees, and sweeps the fill's outputs. All steps revert together on failure.
Current batch constraints require one PT and one order direction per fill batch, although makers may differ. Filter terminal or unsafe orders before submission, account for mixed token decimals, and simulate Blend-backed routes against Soroban CPU and memory limits.