Operations
How user operations flow through the protocol
Operation Lifecycle
All operations follow a similar lifecycle:
1. User Action
User initiates operation (deposit, withdraw, borrow, repay)
2. Validation
- Signature verification
- Balance checks
- Health factor validation
3. State Update
- Share minting/burning
- Position updates
- Index synchronization
4. Async Execution
- Inter-canister calls
- ckAsset operations
- Blockchain transactions
5. Confirmation
- Event notification
- Record updates
- User notification
Inflow vs Outflow Operations
Operation | Direction | Initiated By | State Update |
|---|---|---|---|
Deposit | Inflow | Pool (detected) | Mint supply shares |
Repay | Inflow | Pool (detected) | Burn debt shares |
Withdraw | Outflow | User (signed) | Burn supply shares |
Borrow | Outflow | User (signed) | Mint debt shares |
Inflow Operations
Deposits and repayments are detected by the pool:
- User sends native assets to their deposit address
- ckAsset minter mints tokens to user's subaccount
- Pool timer detects new balance
- Pool transfers to treasury and notifies lending canister
Outflow Operations
Withdrawals and borrows are initiated by the user:
- User signs request with their wallet
- Lending canister validates and updates state
- Pool executes withdrawal asynchronously
- User receives native assets
Subaccount System
The protocol uses subaccounts for user isolation and automatic attribution:
Inflow Subaccounts
Deposit: [0x1, 0x0, length, ...principal_bytes...]
Repayment: [0x2, 0x0, length, ...principal_bytes...]Each user has unique subaccounts derived from their principal.
Outflow Subaccounts
BTC (mapped): [0x3, ...zeros..., ...u128_index...]
ETH (direct): [0x4, ...zeros..., ...20_byte_address...]
IC Principal: [0x5, 0x0, length, ...principal_bytes...]Benefits
- Privacy: No shared addresses
- Automatic attribution: Subaccount identifies user
- Parallel processing: No account contention
- Simplified reconciliation: Deterministic mapping