28 lines
1.7 KiB
Markdown
28 lines
1.7 KiB
Markdown
Status: ready-for-agent
|
|
|
|
# 33 — Settlement loop: leader-only batched USDT payouts
|
|
|
|
## What to build
|
|
|
|
The on-chain settlement loop per ADR-0015, following the mining-pool standard: pay a node when `pending ≥ payout_threshold` OR `time_since_last_payout ≥ max_period`, whichever fires first, with a dust floor so no payout is smaller than it is worth.
|
|
|
|
Only the current Raft leader runs the loop; followers replicate the ledger but never sign. The treasury keypair is loaded only on settlement-capable trackers. Payouts are batched SPL transfers treasury → node wallets on devnet.
|
|
|
|
Config (all dynamic, so the period can grow with volume): dev defaults `period=60s, threshold≈0` so every run is verifiable on-chain; prod defaults `period=24h, threshold=a few USDT`.
|
|
|
|
Settlement history (settlement id, tx signature, node wallet, amount, timestamp) persists in SQLite, replicates across the hive, and is queryable over HTTP. Retries are idempotent by settlement id — a failed or timed-out transaction never double-pays.
|
|
|
|
## Acceptance criteria
|
|
|
|
- [ ] Only the Raft leader settles; followers never sign (asserted in a 3-tracker test)
|
|
- [ ] Trigger: `pending ≥ threshold` OR `elapsed ≥ max_period`; dust floor respected
|
|
- [ ] Batched SPL transfers land on devnet; pending balances zeroed atomically with recorded tx signature
|
|
- [ ] Failed/timeout transactions retry without double-pay (idempotent by settlement id)
|
|
- [ ] Settlement history queryable via tracker HTTP endpoint
|
|
- [ ] End-to-end devnet test: fund client → run inference → node wallet USDT balance increases
|
|
|
|
## Blocked by
|
|
|
|
- `19-binary-data-plane-and-peer-weight-transfer.md`
|
|
- `32-devnet-treasury-deposits.md`
|