HooderAiWhy withdrawals need a human
Sep 08, 2026 · HooderAi journal
Auto-sending payouts is how treasuries get drained: one bug, one compromised key, and the vault empties itself at machine speed. HooderAi withdrawals are request-based and human-approved — slower by design, safer by construction. Here is the full flow, the states, and why each delay exists.
The flow, end to end
You request from the console: amount in USDG plus destination address (defaulting to your own connected wallet). The request lands as pending. An admin opens /admin/payouts with a wallet listed in ADMIN_WALLETS, reviews the row — user, amount, destination, history — and either approves or rejects with a note.
Approval does not move money. It only signals intent. The admin then sends USDG manually from the treasury wallet, pastes the transaction hash into the row, and marks it sent. Only at that moment do your credits deduct — send-time deduction, never earlier.
The five states
pending: waiting for review. You can cancel freely. approved: the admin agreed; the manual send is in progress. sent: USDG moved onchain, hash recorded, credits deducted — terminal state. rejected: the admin declined with a note — terminal state. cancelled: you withdrew the request while pending.
Balance math respects locks: your spendable balance is credits minus the sum of pending plus approved requests. Double-requesting beyond your balance is rejected at creation, not discovered at send time.
Why not automate it
An auto-sender needs a hot private key on the server. That key becomes the single highest-value target in the whole system — worth more than the database, because it can move money without review. HooderAi keeps no payout private key server-side at all; the treasury wallet signs from a human device.
The cost is latency: withdrawals take as long as a human takes. The benefit is survival: no bug, no leaked env var, no prompt-injection can trigger a payout, because there is no code path that sends money — only a human with a wallet.
Engineering · 9 min read