Immunity

Immunity is a decentralized AI agent security open-source protocol. Publish antibodies to protect the network and be rewarded for it.

This network is fully autonomous with agents interacting within it to protect themselves and at the same time protect the whole network and earn from it from various avenues. Sybil resistant and using game theory to make sure there is no inventive to attack but to participate instead.

How it's protected, there is like 5 walls for a possible attacker to go through to land a successful attack which is almost impossible to do.

1. ENS subdomain is needed to call the smart contract functions at its core. This subdomain is attached to the agent and controlled entirely by the contract itself and no other entity. This is important because REPUTATION records lives on ENS for the agent. So there is an "entry fee" of minting this subname which the agent pay itself. It's cheap because I mint subnames from my custom L2Resolver on Base, but still an entry blockade for random wonderers looking to hammer the network.

2. Corroboration principle. When someone publish an antibody, by default it is only ADVISORY meaning it will not automatically block a transaction on itself (tho the SDK operator could choose to do so but its not recommended). For an antibody to MATURE and grow from advisory to auto-block, it needs the corroboration of K agents WITH GOOD REPUTATION that mints the same antibody because it's a good one (K being by default 3 but can expend with the network growth). So if a bad actor tries to blacklist the genuine Uniswap Router contract for example to cause DoS of the network, it would not be mature enough to warrant an automatic block.

3. Escrow. The fees one earns while the antibody is not mature (not yet reached the required K corroboration) are locked. If at some point the antibody is eliminated from the network because of a challenge, the operator lost the potential gains he could have made on an attack. When an antibody reach maturity, the escrow is released.

4. Bond. Each publishing of an antibody requires a BOND based on its severity (the more severe the more expensive the bond is) and also there is a multiplier for producing an antibody for something the network knows to be good which I call the "protected-set", for example the Uniswap router contract is part of that ever-growing set. In this case, the bond multiplier goes to x1000, brining the bond minimally to 1000$!!! to publish.

5. If somehow something nefarious reach the network, any agent can challenge it. The challenger must produce a bond equivalent to challenge it and then we have 3 JUDGES (different LLM models : ChatGPT, Claude and Gemini) doing an evaluation on the EVIDENCE that produced the antibody to come to a consensus about if its a true antibody or a false positive, the winner get the other party's bond.

6. Reputation. To be considered a valid "K" that helps mature an antibody it requires a good reputation. Each time an agent is contested in a challenge and lose it takes a serious cut in its reputation. Reputation is extremely hard to gain, but easy to lose. Growing it back takes more time than losing it.

There exists various AI agent prototypes than can extract revenues from this network and I provide a Docker image ready to use for those case so anyone can participate in the network.

First we have the PUBLISHERS. Those agents check off chain for any signal that can help protect the network to mint new trusted antibody, this could be watching specific security X account, following the news, etc. whatever input source and act on it. their sole goal is to mint GOOD antibody to not be slashes and benefits.

Second are the HUNTERS. Those agents constantly monitor the new antibodies and tries to immediately challenge those that it judge are not good to make sure the network is clean and steal the bond of those antibody.

Third are the CORROBORATORS. These agents watches new antibody and try to find good one to mature and also benefit from. Because the whole concept is a same antibody can exist multiple times to strengthen the network and the pick is always random when an agent check its security against the pool so everyone has a chance to earn from a good antibody if they mint it.

Of course there can be hybrid and custom ones. But essentially, there is a real model underneath that can yield revenues to those agents on top of providing an excellent security.

Each "check" of security cost 0,01$ USDC. This is to fuel the network and to pay for the CRE compute with Claude. If you get protected from an existing antibody, the LLM call is avoided saving network cost effectively and the agent that published the antibody get 80% of the fee. The rest goes to treasury.

This will give a large security from prompt injection detection, to malicious call_data, graph attack, byte code, etc.

Each antibody gets its own CVE like identifier with a proper detail page showing the LLM reasoning behind a blockade. This page also shows all the protection it did and how much money it theoretically saved by blocking a transaction broadcast.

How to use it is very simple, operator downloads the SDK and integrate the immunity block code to surround the broadcasting of a transaction.

Another great feature is with the relayer, I can mirror mature antibodies to other chains and it unlocks many composability features such as integration with a Uniswap v4 hook! I did a hook that feeds from the immunity protocol and thus agents minting antibody effectively protects people using protected pools with this hook that don't even know immunity exists! It reverts transaction when it hit a matching antibody. The simulation fails directly when trying to sign so you don't even have too pay gas to see it will be blocked.

Every repository was claimed, snapshot and preserved with CodeQuill @ https://app.codequill.xyz/explore/immunity-protocol

I started this project in Open Agent hackathon and this is for the continuity track. It is an immense improvement on the entire protocol on all front. It also merges concepts from my previous Cannes hackathon project ENShell.

So essentially there has been a complete rework of the entire foundation to make it sybil resistant and hardened the tokenomics. The previous version had no "challenge" implementation and no sybil resistance. This was my first goal.

My second goal was to replace the tech stack to something more mainstream that offers me more opportunities of integrations with other applications and protocols. Previously built on 0G, it now lives on Base L2 network. The TEE computation is now done with Chainlink CRE (which I used previously with ENShell and I very much enjoyed). Storage is now done with Lighthouse (Filecoin on Base L2 which is the solution I use with CodeQuill in production so it all fits together for a cohesive infrastructure in my project).

My third goal was to integrate a reputation system as part of my counter sybil solution and ENS was the obvious choice for it because they are the leading reference in decentralized identity because you can query subnames from anywhere anytime easily and read records. I did my own L2Registry because Durin was not working with ENSv2 and my architecture MUST run on a cheap L2 like base for fee reasons, so for my contract to be the sole owner of the ENS subname and records I need a proper bridge and so I had to code the resolver which was a good thing because it allowed me to fully customized it for my needs meaning my SignatureVerifier gateway process all *.immunity.eth unclustering the contract itself with the names as an array. Also I was able to surface specific records like immunity.reputation easily with the gateway too. I would want to go to a fully decentralized solution for this like trustless storage proof (like dm3 or bedrock), but on testnet the settlement is way too long and not worth. the Gateway now lives on my Fly.io infrastructure like every other servers of the project.

Total I have 8 machines :

• App
• Api
• ccid-gateway (ENS CCID gateway for resolution everywhere of immunity.eth domain)
• gateway (lighthouse gateway to avoid api key usage in the SDK)
• database
• relayer (pushes mature Base antibodies to other chains for composability (see uniswap integration))
• indexer (to keep the app fresh and fast)
• fleet (45 submachines executing transactions)
• cre (simulation listening equivalent of testnet deploy)

The SDK offers a great parameters that allows for the experience optimization like choosing what to do with advisory antibodies, etc. It was updated to match the new smart contracts integration.

The foundation is 9 smart contracts separated in app domain :

• ENS contracts (L1Resolver, L2Registry)
• CRE evaluation receivers (CREVerdictReceiver for judges and NovelVerification for detection)
• Sybil resistance concerns (ChallengeManager, ProtectedSet and Reputation)
• Core (ImmunityRegistry itself and the PublisherRegistrar for minting subnames)

I separated everything in many repositories for clarity and separation of concerns. Everything lives @ https://github.com/immunity-protocol. Repos flagged as archived are from the old version with 0G and Gensyn essentially. All the other ones are actively used and important. Everything for the track is in the "continuity" branches over all those repos. Please consult all repos because I was not able to submit them all in the form.