Chainlink's Payment Abstraction V2 is a permissionless Dutch auction system for converting fee tokens into LINK. It integrates with CowSwap's GPv2 settlement, uses Chainlink Data Streams with AggregatorV3 fallback pricing, and manages 10 distinct privileged roles across a multi-contract architecture.
We ran our AI audit engine against the codebase during the live Code4rena competition. This is what we found — and what it means for the state of AI security auditing.
The Target
13
Contracts in Scope
1,060
nSLOC
$65K
Prize Pool
10
Privileged Roles
Payment Abstraction V2 replaces Uniswap V3 fee conversions with a permissionless Dutch auction where any participant can bid on allowlisted assets. The system integrates with CowSwap solvers via EIP-1271 signed orders and uses Chainlink Data Streams as the primary price source with AggregatorV3 as fallback.
This is the kind of target that separates real security tools from surface-level scanners: small codebase, deep complexity, multi-protocol integration, and a well-funded team that has invested in secure engineering.
Two AI Auditors. Same Target.
V12 (Zellic AI)
- •5 findings (1 Critical, 4 Low)
- •All 5 judged out of scope by C4
- •No trusted role cross-referencing
- •No PoC generation
- •No defense verification
RedVolt
- •18 consolidated findings across 6 attack categories
- •3 valid QA findings with runnable Foundry PoCs
- •All 10 roles mapped and verified against findings
- •12/13 PoCs compiled and executed (92.3%)
- •5 defense mechanisms verified with mathematical proof
Zellic's V12 — marketed as "the only autonomous Solidity auditor that reliably finds Highs and Criticals" — produced 5 findings. Their Critical finding (old auction approvals persist after rotation) requires a compromised DEFAULT_ADMIN_ROLE to exploit. The contest rules explicitly state this role is granted to a Timelock — making it a trusted-role finding.
RedVolt independently discovered the same approval pattern, but classified it correctly by cross-referencing the trusted roles table.
Audit Results
3.3 hrs
Total Audit Time
18
Consolidated Findings
92.3%
PoC Success Rate
6
Attack Categories
RedVolt's engine analyzed the codebase across six attack categories: access control and centralization, arithmetic and rounding edge cases, oracle security, protocol integration risks, automation and keeper issues, and reentrancy paths. Every finding went through automated PoC verification using Foundry.
What We Found — And What We Verified
Our engine identified 18 risk areas. After systematic verification with Foundry PoCs, here is what we confirmed:
Defense 1: Solady mulDivUp Prevents Zero-Rounding Attacks
Our analysis flagged that dust bids could result in zero assetOutAmount, allowing bidders to receive free tokens. The PoC proved this is impossible:
ℹ️Verification Result
Solady's mulDivUp(x, y, z) computes (x * y + z - 1) / z, which always returns >= 1 for non-zero inputs. Combined with the $100 minimum bid check, zero-payment bids are mathematically impossible. Finding invalidated.
Defense 2: Role Separation Blocks Cross-Function Reentrancy
Our analysis identified that bid() uses a custom s_entered guard that only protects bid() and isValidSignature(), not performUpkeep(). A callback during bid() could theoretically reenter performUpkeep().
ℹ️Verification Result
performUpkeep() is independently protected by AUCTION_WORKER_ROLE, granted only to the WorkflowRouter. An attacker in the bid callback cannot call performUpkeep because they don't hold the role. The PoC confirmed: vm.expectRevert() on unauthorized performUpkeep call. Finding invalidated.
Defense 3: Cascading Oracle Validation
Our analysis flagged missing independent staleness validation on the AggregatorV3 fallback. The PoC revealed a more nuanced picture:
ℹ️Verification Result
_getAssetPrice() returns an isValid flag that correctly reflects staleness. All callers — checkUpkeep(), bid(), performUpkeep() — check this flag before using the price. The validation exists at the caller level, not the getter level. Downgraded to QA.
Defense 4: Trusted Role Architecture
Seven of our findings involved privileged roles. The verification process:
| Area | What to Check |
|---|---|
| DEFAULT_ADMIN_ROLE | |
| ASSET_ADMIN_ROLE | |
| PRICE_ADMIN_ROLE | |
| FORWARDER_ROLE | |
| AUCTION_WORKER_ROLE | |
| AUCTION_BIDDER_ROLE | |
| ORDER_MANAGER_ROLE |
All 7 trusted-role findings correctly excluded from submission.
3 Valid QA Findings Confirmed
Finding
- •L-01: Negative Chainlink price causes SafeCast revert
- •L-02: Missing answeredInRound check on AggregatorV3 fallback
- •L-03: Off-by-one at exact auction expiry timestamp
Impact
- •DoS on all auctions for affected asset until feed recovers
- •Incomplete round data could be used as price source
- •Brief MEV window at maximum discount before auction flagged as ended
All three confirmed with runnable Foundry PoCs using the contest's provided test suite.
The Numbers
18
Consolidated Findings
5
Defenses Verified
10
Roles Mapped
92.3%
PoC Success
V12 (Zellic AI)
- •5 consolidated findings
- •3 attack categories
- •No trusted role verification
- •No PoC generation
- •No known issue cross-reference
- •No defense verification
- •0 valid findings (all out of scope)
RedVolt
- •18 consolidated findings
- •6 attack categories
- •All 10 roles mapped and verified
- •12/13 PoCs compiled (92.3%)
- •3 exclusions identified
- •5 defense mechanisms confirmed
- •3 valid QA findings with PoCs
What This Means
A Clean Audit Is Not a Failed Audit
💡The Right Framing
RedVolt correctly identified 18 risk areas in Chainlink's Dutch auction system. After verification, the protocol's multi-layered defenses — role-based access control, Solady's rounding-up math library, and cascading validation checks — properly mitigate all identified risks. The audit confirmed the codebase is well-hardened.
Not every audit finds critical bugs. Some audits confirm the code is solid — and that confirmation has value. When RedVolt analyzes over 100 potential risk areas and systematically eliminates each one with mathematical proof, that is a stronger statement than "no findings."
Protocol teams get:
- A verified map of the access control model
- Proof that math libraries prevent edge-case exploits
- Confirmation that oracle fallback logic handles degraded states
- Evidence that reentrancy protections cover cross-function paths
Context Understanding Separates Scanners from Auditors
The fundamental question for AI security auditing is no longer "can it find bugs?" It is: can it understand context?
- Can it read a trusted roles table and correctly exclude admin-only findings?
- Can it verify that
mulDivUpprevents zero-rounding instead of just flagging "potential rounding issue"? - Can it generate a Foundry PoC that proves an attack path is blocked?
- Can it distinguish between a known issue and a novel vulnerability?
V12's Critical finding required a compromised Timelock to exploit. RedVolt identified the same pattern but correctly classified it as a trusted-role issue. That distinction — between code that could be exploited by an admin and code that can be exploited by an attacker — is what separates a vulnerability scanner from a security auditor.
Audit Performance
RedVolt completed the full analysis in 3.3 hours with zero human intervention — compilation, static analysis, AI-powered vulnerability hunting, PoC generation, and report synthesis. The engine produced a 48-page PDF report with severity-calibrated findings and verified PoCs.
💡Our Commitment
We audit against real protocols in live competitions. We verify every finding with PoCs. We publish the results. That is what accountability looks like.