Concept
Two-Phase Execution
A swap is not a single atomic action. It is an authorization (a grant from the holder) plus a settlement (execution by the counter-party). This separation prevents front-running, grants the holder full control over limits, and enables composable DeFi.
Why two phases?
In a traditional AMM, a swap is one atomic transaction: the user signs, the pool executes, the output is whatever the pool state happens to be at that moment. This creates problems:
- Front-running: The mempool reveals the user's intent; bots can sandwich the trade.
- No limits: The user cannot set a maximum slippage or minimum output -- they get whatever the pool state dictates.
- No composability: The swap is a black box; it cannot be combined with other actions atomically.
CenterChain's two-phase model solves all three.
Phase 1: Authorization (MsgAuthorizeSwap)
The holder creates a SwapAuthorization -- a signed grant that specifies exactly what they're willing to accept:
- Input denom and maximum input amount
- Output denom and minimum output amount (slippage protection)
- Expiration -- block height after which the authorization expires
- Authorized counter-party (optional -- can be open to anyone)
The authorization is stored on-chain with a unique ID. It does not move tokens. It only records the holder's intent. The holder can revoke it at any time before settlement with MsgRevokeSwap.
Phase 2: Settlement (MsgSettleSwap)
The authorized counter-party (or anyone, if open) calls MsgSettleSwap with the authorization ID. The module:
- Validates the authorization exists and hasn't expired
- Checks the pool has sufficient liquidity
- Computes the output amount using the pool's current state
- Only settles if output ≥ minimum output amount -- otherwise the entire settlement fails
- Moves tokens through the compliance layer (
CanSendTokens) - Emits a settlement event with exact amounts
If the pool moved against the holder (output < minimum), the settlement fails cleanly -- the authorization remains valid and can be re-attempted or revoked.
What this enables
No front-running
The authorization commits to a minimum output. Bots cannot sandwich -- the settlement either meets the minimum or fails.
User-defined slippage
Minimum output is set by the holder, not the pool. True slippage control.
Composability
Authorization can be created in one tx, settled in another, combined with other actions in multi-message txs.
Revocability
Holder can revoke anytime before settlement. Full control until execution.
Messages
- MsgAuthorizeSwap -- Create a swap authorization (holder).
- MsgRevokeSwap -- Revoke an active authorization (holder).
- MsgSettleSwap -- Execute the swap against an authorization (counter-party).
Read the full specification
Full message schemas, event schemas, gas cost analysis, and integration patterns.