ApprovalGuardian

ApprovalGuardian is an autonomous DeFi protection system that automatically detects protocol exploits and revokes dangerous  
 token approvals before users lose funds.                                           
                                                                
 The problem it solves: every time you interact with a DeFi protocol you grant it an ERC-20 approval unlimited permission to
  spend your tokens. Most users forget these approvals exist. When a protocol gets exploited, attackers drain every approved  
 wallet within seconds. By the time a human notices and manually revokes, the funds are gone.                 
                                                                
 The system runs three Chainlink CRE workflows in sequence. The first is a cron-triggered scanner that continuously monitors  
 registered wallets across Ethereum, Arbitrum, and Base for open approvals pointing to known threat contracts. The second
 watches for on-chain exploit signals specifically Paused and LargeDrain events emitted by monitored DeFi protocols. When
 one fires, every node in the Chainlink Decentralised Oracle Network independently queries DefiLlama for TVL data, checks the
 protocol's on-chain paused state, and computes a threat score. These scores are aggregated using Byzantine Fault Tolerant
 median consensus no single node can manipulate the result. If the consensus score crosses the user's configured sensitivity
  threshold, the third workflow executes: it finds every open approval to the threat contract, assembles a cryptographically
 signed RevocationReport, and submits it on-chain through the CRE Forwarder. The ApprovalGuardian smart contract verifies the
 DON's collective signature and calls guardianRevokeApproval on the token, zeroing the allowance directly.

 CRE is not incidental to this project it is the only reason the project is possible. The BFT consensus prevents any single
 party from maliciously revoking legitimate approvals. The writeReport mechanism means no private key ever needs to sit on a
 server. The native EVM log trigger means threat detection happens at block speed, not on a polling delay. Without CRE, the
 system would either require trusting a centralised server to make revocation decisions which is itself a critical attack
 surface or require users to manually sign every revocation, defeating the entire purpose.

 Users register their wallet with a sensitivity level (conservative, moderate, or aggressive), set their preferred scan
 schedule, and connect Telegram for alerts. From that point the system is fully autonomous: exploit fires, DON detects,
 consensus reached, approvals revoked, Telegram notification sent all without any user action.

ApprovalGuardian is built across four layers.                                         
                                                                
 The on-chain layer consists of two Solidity contracts deployed on Ethereum Sepolia. ApprovalGuardian extends Chainlink's   
 ReceiverTemplate, making its onReport function only callable by the CRE Forwarder contract. It stores wallet registrations  
 with sensitivity levels and executes revocations when a valid DON-signed report arrives. MockProtocolToken is a        
 guardian-aware ERC-20 that adds a guardianRevokeApproval function — since standard ERC-20 approve only works for msg.sender,
 this custom function lets the Guardian contract zero out a user's allowance on their behalf, protected by an onlyGuardian   
 modifier.                                                          

 The automation layer is three CRE workflows written in TypeScript and compiled to WASM. Each workflow is self-contained — no
 shared imports, all config inlined — because CRE's WASM runtime cannot resolve paths outside the workflow directory. Workflow
  1 uses CronCapability for scheduled scanning, EVMClient.filterLogs to find Approval events across multiple chains, and
 HTTPClient to query DefiLlama TVL. Workflow 2 uses EVMClient.logTrigger to watch for exploit events in real time, runs threat
  scoring across the DON using consensusMedianAggregation, and triggers Workflow 3 via HTTP when the score is high enough.
 Workflow 3 uses HTTPCapability as its entry point, scans for open approvals, assembles a RevocationReport, and calls
 runtime.report followed by evmClient.writeReport to submit the DON-signed result on-chain.

 The backend is a Bun HTTP server that acts as the bridge between the frontend, CRE CLI, and Supabase. It spawns cre workflow
 simulate as subprocesses and streams the output to the frontend as Server-Sent Events in real time. It reads wallet and
 protocol configuration from Supabase and writes it to each workflow's config.staging.json files. It long-polls the Telegram
 Bot API to auto-register users who message the bot, and fans out alerts to every registered subscriber after simulations
 complete. It also manages Tenderly Virtual TestNet creation via the Tenderly API and can run all three workflows against a
 live mainnet fork.

 The frontend is a Next.js app with wagmi and RainbowKit for wallet connectivity. Users register their wallet directly through
  MetaMask — no private key ever touches the backend. The dashboard streams live CRE simulation logs into a shared terminal,
 shows open approvals via Supabase realtime subscriptions, displays a live threat feed, and walks through the full three-step
 demo pipeline. The configure page lets users set their scan schedule, add wallets and protocols, and sync everything to the
 CRE workflows in one click.