Frequently Asked Questions

Yes, two minimal additions are required: (1) a SentinelState PDA initialized once by your admin, and (2) a single require! guard at the top of each withdrawal instruction. No other program logic needs to change.

Your protocol continues to function normally. SentinelGuard operates entirely off-chain — its downtime cannot halt or disrupt legitimate user transactions. You simply lose automated pausing until the watcher is restarted.

An authorized administrator key must sign a transaction that sets paused = false on the SentinelState PDA. The watcher does not auto-resume — a human must explicitly approve the unpause after reviewing the alert.

Any withdrawal transaction that lands after the pause CPI is confirmed will revert with ProtocolPaused. Transactions that were already finalized before the pause complete normally. There is no retroactive effect.

The watcher consumes a Geyser gRPC stream and evaluates slots in real time. End-to-end — from the malicious transaction hitting the RPC to the pause CPI landing on-chain — the reaction time is typically under 400ms.

The watcher is network-agnostic. Point HELIUS_API_KEY and SENTINEL_PROGRAM_ID at devnet, testnet, or mainnet-beta and it works identically. The public hosted instance runs on devnet for demonstration purposes.

The SDK and public threat feed are free. Running the self-hosted watcher requires a Helius API key (free tier covers devnet) and your own PostgreSQL + Redis infrastructure. There is no per-alert fee.

You can via MIN_SEVERITY_TO_PAUSE, but scores below 60 represent LOW-confidence signals where false positive rates increase significantly — especially in high-volume pools with frequent large swaps. We recommend staying at 60 or above in production.