Requests (Fallback Approval Queue)
The Requests tab is the fallback per-call approval surface for agent operations that don’t carry an SLK. The recommended path is SLK-first (Proposals, SLKs, Activity) — every agent op authorized up front by a typed policy, then dispatched without prompting.
If an MCP request arrives without an SLK token, the daemon stores it here and waits for the operator. This is useful for one-off operator-initiated runs and for clients that don’t yet speak the SLK Proposal Protocol.
What shows up here
- wallet list, details, balance, transactions, token list requests
- native-asset send (SOL, ETH, MATIC, BNB) and token send requests
- swap requests (Solana only)
- message / typed-data / hash signing requests
- wallet create, import, and delete requests
- address book list and add requests
- WalletConnect-initiated session signing requests when no SLK
with
can_wc_connectmatches the dApp
Controls
| Key | Action |
|---|---|
Enter | Open request detail (action, params, requesting client) |
y | Approve |
n | Deny |
d | Delete from history |
e | Copy explorer URL (when the call produced a tx) |
The daemon blocks the agent’s call until you decide. Most agents will time out after 30s — long enough for interactive review, not for a long break.
When to prefer SLK over Requests
Use the Proposals → SLK path whenever the agent will perform more than one or two operations, or any signing op. SLK creation is a single approval that grants typed, scoped, time-bounded autonomy to the agent without per-call friction.