Paladin Protocol

What is it?
Paladin Protocol is an open-source exploit detection and response system for DeFi protocols. It is like having a security guard who never sleeps on guard against attack,s so that your money is secured before it is attacked by counterfeit hackers.
Its name derives from the concept of the sworn protector- a paladin during medieval times was a religious fighter who was defending people. This is the case with DAO treasuries.
What problem does it solve?
The reason I got going on this is as follows: in 2023 alone, 1.7 billion was stolen in DeFi. What shocked me, however, was the realization that 68 percent of those hacks were not original at all but imitations.
What occurs is that a given attacker will discover a bug in one protocol, exploit it, and thereafter, in a matter of hours (in some cases under 2 hours). He/she will execute every other protocol with the same code using the same exploit. Through this, Cream Finance lost $130M in various forks. Nomad Bridge was hit with 41 copycat attacks and a price of 190M in as little as 2 hours.
The issue is that the manual response is too slow. By the time the security teams realize there was an attack, they analyze the occurrence, and issue a warning on the rest of the protocols, the copycats have already occurred. We are discussing 6-12 hours on the part of human beings and minutes on the part of the attackers.
And I reasoned: would it not be nice to notice the pattern of the first strike and automatically secure the other susceptible protocols until the copycats strike?
How it works:

Step 1 - Detection:
The system identifies blockchain transactions seeking exploit signatures. It relies on heuristics such as patterns in abnormal gases, using flash loans, signs of reentrancy, bizarre value transfers, and all the other warning signs that something suspicious is going on.
Whenever it detects a suspicious transaction, it assigns it an anomaly score.

Step 2 - AI Analysis:
In case of a high score, the transaction data will be sent to an artificial intelligence analyzer. I have Ollama version 3.1:8b running locally (intended to use Claude API but changed due to cost/speed consideration).
In the case of the transaction trace and the contract source codes, the AI calculates:
Is this actually an exploit?
What is the type? (reentrancy, flash loan attack, oracle manipulation, etc.)
Which is the vulnerable pattern of the code?
How severe is it?

Step 3 - On-chain Recording:
Each detection is used to place a record on the Risk Registry smart contract on Arbitrum Sepolia. This leaves you with an unalterable audit trail - you can not counterfeit or destroy these records. Any person can confirm that something was identified and at what time.

Step 4 - Autonomous Response (built but not simulated during demo):
The Guardian smart contract is programmed to react according to the level of risk:
Critical threats (9-10): Emergency withdrawal of all funds
High threats (7-8): Withdrawal partially (80%)
Medium threats (5-6): Alert governance.
Minimal threats (3-4): Improved surveillance.

Step 5 - Orchestration:
Chainlink CRE is the binding factor. The brain does all the coordination to monitor, invoke the AI, and write on-chain, and can call the Guardian contract. In the absence of CRE, I would require a centralized backend server, which contradicts the entire idea of being trustless.
The angle of the copycat protection:
After an exploit pattern has been discovered, the system is able to scan other protocols within a portfolio of a DAO that have the vulnerability. Similar to when Protocol A is struck with a reentrancy attack, it will verify whether Protocols B, C, and D share the same bug and safeguard them before they can be attacked.
That is the most important innovation, not only to identify individual exploits, but to thwart the wave of copycat attacks.

Smart Contracts (Solidity + Foundry):
I built three main contracts:
VulnerableProtocol.sol - A lending protocol that has a reentrancy bug that is deliberately introduced. This is to demonstrate purposes in order to demonstrate that the detection can indeed work. It is the usual error, sending ETH without having updated balances, and then you can call withdraw and drain recursively.
Guardian.sol - The autonomous response contract. The CRE workflow is the only one to call its emergency functions (access control through OpenZeppelin AccessControl). It has lockout periods to prevent over-spamming with withdrawals, a maximum amount of money you can withdraw at any time as specified by the protocol, and forwards all the money rescued to a secure address (would look like a Gnosis Safe in reality).
RiskRegistry.sol - Read-only on-chain database of every detection. Stores are taking advantage of type, severity, AI analysis hash (on IPFS), affected protocols, timestamps--everything you require to have a full audit trail. Once it is written here, it is forever.
The three are all deployed and tested on Arbiscan (Arbitrum Sepolia testnet).

CRE Workflow (JavaScript + YAML):
This was the first time I used Chainlink CRE, and honestly,y it is very cool after getting familiar with its use. These components of the workflow are:
exploitDetector.js - Retrieves block transactions, scores anomalies. Verifies gas consumption, searches flash loans, and identifies reentrancy patterns. A score above 60 /100 is flagged.
aiAnalyzer.js - Makes a call tothe Ollama API with a structured prompt with a transmission of transaction data and contract source code. Splits the JSON response to obtain exploit classification and confidence scores.
portfolioScanner.js - Requests Etherscan API to fetch source code, finds code similarities between the exploited contract and protocols that were in the portfolio of the protocols in the DAO. In case similarity is greater than 70, it does an AI deep dive.
responseExecutor.js - Decides on the course of action according to the level of risk and carries it out through the Guardian contract. Has re-try logic and error management.
workflow.yaml - The CRE file configuration that makes it all work. Specifies triggers (new blocks), steps (detection → analysis → recording → response), and the flow of data between them.

Frontend Dashboard (Next.js):
Its technology is Next.js 14, TypeScript, and Tailwind. Interacts with blockchains using wagmi and viem. Shows:
Risk score protocol health cards.
Live alert feed on the detection of threats.
Visualization of risk timeline using Recharts.
Has a connection to the wallet through RainbowKit.
The frontend was the least hard (the part I was honest about); most of my time was spent on the contracts and the CRE workflow.

Tech choices and why:
Foundry over Hardhat - Faster to test, enhanced dev experience.
Ollama against Claude API - Cost and speed. Can run in the background without API constraints
CRE is more decentralized at the backend - Trustless orchestration, there is no single point of failure.
Arbitrum Sepolia - Meet Ethereum testnet speed, but at a lower cost.

The entire stack is modular in design. Ollama may be replaced by Claude or GPT-4. You can monitor any EVM chain. The contracts are not chain-specific.