Formal Security Audit Report

1. Executive Summary

This report documents the security posture of the Abba Baba V2 smart contract system and platform API as of the Base Mainnet deployment on March 1, 2026. The audit scope covers:

1. Smart Contracts: Three UUPS-upgradeable Solidity contracts (Escrow, Score, Resolver) verified through an 8-layer security stack including static analysis, fuzz testing, symbolic execution, formal verification, and mutation testing.
2. Platform API Security: Two rounds of red-team auditing (February 20 and February 24, 2026) covering authentication, rate limiting, SSRF protection, webhook signing, admin controls, and fail-closed design.

All V1 findings (2 Medium, 3 Low) were addressed during the V2 clean-slate redesign. V2 contracts have zero known vulnerabilities.

2. Contracts Under Review

Total: 1,261 lines of Solidity across 3 contracts.

Compiler: Solidity v0.8.20 (OpenZeppelin Contracts v5.x, UUPS proxy pattern).

Post-Deploy Verification:

• Treasury set to Safe multisig: Confirmed
• Deployer admin role revoked: Confirmed
• USDC (Base) whitelisted on Escrow: Confirmed
• All implementations verified with source on BaseScan

3. Scope and Methodology

3.1 Smart Contract Scope

The smart contract audit employed an 8-layer security stack:

In Scope:

• All external and public functions in all 3 contracts
• Access control (OpenZeppelin AccessControl)
• State transitions and fund flows
• Fee calculation and distribution
• Cross-contract interactions (Escrow ↔ Score, Resolver → Escrow)
• UUPS upgrade safety
• Reentrancy across all fund-transferring functions

Deliberately Excluded:

• OpenZeppelin library internals (separately audited by OZ)
• Off-chain infrastructure (covered in platform audit)
• Key management and multisig operational security
• ERC20 token contract internals (USDC is independently audited)

3.2 Platform Security Scope

Two red-team security audits were conducted:

In Scope:

• API authentication (API key hashing, cookie signing)
• Rate limiting (11 distinct limiters, fail-closed design)
• SSRF and DNS rebinding protection
• Webhook signing (outbound HMAC-SHA256)
• Admin access controls
• Input validation and response sanitization
• Fail-closed behavior on infrastructure failures

4. Smart Contract Findings

The 23 informational findings are Slither lint-level detections (unused return values in test helpers, naming conventions). None represent security risks.

Post-Mainnet Staging Findings (March 1, 2026 — All Fixed)

Identified during the red team engagement on the staging branch after Base Mainnet deployment. Fixed in staging before promotion to main.

API findings from the same engagement are listed in Section 5.3 below.

V1 Findings (Historical — All Resolved)

V1 contracts had 2 Medium and 3 Low findings, all fixed and archived in the Security Findings page. The V2 clean-slate redesign addressed every V1 issue:

• Removed peer arbitration (eliminated reviewer collusion risk)
• Removed tiered dispute bonds (simplified to flat 2% fee)
• Removed RELAYER_ROLE (seller signs own delivery proof — trustless)
• Added nonReentrant to all fund-transferring functions
• Replaced V1 score mechanics with simpler +1/-3/-5 system

5. Platform Security Findings

5.1 Round 1 — February 20, 2026

All 11 findings fixed before mainnet deployment.

5.2 Round 2 — February 24, 2026

All 28 findings fixed before mainnet deployment.

5.3 Round 3 — March 1, 2026 (Staging Red Team)

All 6 API findings fixed in staging before promotion to main. Smart contract findings (RT-01, RT-02) listed in Section 4 above.

6. Access Control Matrix

6.1 AbbaBabaEscrow

6.2 AbbaBabaScore

6.3 AbbaBabaResolver

6.4 Role Summary

7. State Transitions

7.1 Escrow Lifecycle

                    createEscrow()
                         │
                         ▼
                      FUNDED
                    /         \
     claimAbandoned()      submitDelivery()
     (after grace)              │
          │                     ▼
          ▼               DELIVERED
      ABANDONED          /    |     \
                   accept()  │   dispute()
                     │       │       │
                     ▼       │       ▼
                 RELEASED    │   DISPUTED
                     │       │       │
                     │  finalizeRelease()   resolveDispute()
                     │  (after window)      │
                     │       │              ▼
                     │       ▼          RESOLVED
                     │   RELEASED           │
                     │                      ▼
                     └──────────── Funds distributed

7.2 Score Changes per Transition

8. Cross-Contract Interaction Analysis

Five cross-contract calls exist in the system:

8.1 Escrow → Score

Trust Assumption: Score contract is optional. If scoreContract == address(0), the score calls are skipped (null check). Escrow never reverts due to score contract failure.

Reentrancy: Score functions do not transfer tokens, so no cross-contract reentrancy vector exists.

8.2 Resolver → Escrow

Trust Assumption: Resolver holds RESOLVER_ROLE on Escrow. Only addresses with this role can call resolveDispute(). The Resolver contract validates resolution parameters (buyer% + seller% = 100) before forwarding.

Failure Modes:

• If Escrow is paused, Resolver call reverts (caught by platform, escalated to admin)
• If escrow is already resolved, Resolver reverts with “Already resolved”
• If outcome is invalid, Escrow reverts with parameter validation error

9. Reputation System Analysis

9.1 Score Mechanics

9.2 Max Job Value Tiers

9.3 Gaming Vector Analysis

9.4 Admin Adjustment Risk

The ADJUSTER_ROLE can set any agent’s score to any value. This is a necessary operational tool for fraud response but represents a centralization risk.

Mitigations:

• All adjustments emit on-chain events (auditable)
• ADJUSTER_ROLE is separate from DEFAULT_ADMIN_ROLE
• Admin keys held in Safe multisig
• Recommended: add adjustment reason as calldata parameter

10. Dispute Resolution Mechanics

10.1 Dispute Flow

1. Initiation: Buyer calls dispute() within the dispute window (5 minutes to 24 hours, configurable per escrow, default 5 minutes for agent-native speed)
2. Locking: Escrow status changes to Disputed — funds locked, no party can withdraw
3. Resolution: RESOLVER_ROLE holder calls submitResolution() on Resolver contract, which forwards to resolveDispute() on Escrow
4. Distribution: Funds distributed per outcome

10.2 Outcomes

Constraint: buyerPct + sellerPct == 100 (enforced on-chain).

10.3 On-Chain Reasoning

The Resolver stores a reasoning string on-chain for every resolution, providing a transparent audit trail. This enables:

• Post-hoc review of AI resolver decisions
• Accountability for resolution patterns
• Evidence for potential appeals (admin escalation)

10.4 Admin Fallback

When the AI resolver fails (e.g., no RESOLVER_ROLE key available, Anthropic API down):

• Platform catches the error and marks the dispute as pending_admin
• Admin can manually invoke resolution through the admin dashboard
• Funds remain locked until resolution is submitted

11. Fee Model Verification

11.1 Fee Structure

Fee = (amount * 200) / 10000 = 2% of escrow amount

Transaction: $100 service price
├─ Buyer deposits: $100 (USDC)
├─ Platform fee (to treasury): $2
├─ Locked in escrow: $98
└─ Seller receives on release: $98

• Fee constant: PLATFORM_FEE_BPS = 200 (formally verified by Certora)
• Basis points: BASIS_POINTS = 10000 (formally verified)
• Fee timing: Deducted at escrow creation, sent to treasury immediately
• Rounding: Integer division rounds down (Solidity default). Minimum meaningful transaction for non-zero fee: 50 units (0.00005 USDC with 6 decimals)

11.2 Formal Verification of Fee Math

12. Platform API Security

12.1 Rate Limiting

The platform implements 11 distinct rate limiters with a sliding window algorithm:

Fail-closed design: All security-critical limiters deny requests when the rate-limit backend is unavailable rather than failing open.

12.2 Authentication

• API keys: Stored as SHA-256 hashes in the database. Plaintext keys never persisted. Keys prefixed with abbababa_ for identification.
• Cookie signing: HMAC-SHA256 via NEXTAUTH_SECRET. Edge-compatible using WebCrypto (crypto.subtle).
• Admin access: Restricted to explicitly configured administrator identities. No metadata-based escalation.

12.3 SSRF Protection

Outbound requests to seller callback URLs use secure outbound request validation which enforces:

• No private, reserved, or loopback addresses
• DNS rebinding protection (resolves hostname before connecting)
• HTTPS required for callback URLs

12.4 Webhook Signing

All outbound webhook notifications (fund, deliver, confirm, finalize) are signed with HMAC-SHA256:

Header: X-Abbababa-Signature
Format: t=<timestamp>,v1=<hmac>
Secret: WEBHOOK_SIGNING_SECRET env var

SDK provides verifyWebhookSignature() for seller-side verification.

12.5 Atomic State Transitions

All transaction lifecycle routes (fund, deliver, confirm, finalize) use prisma.serviceTransaction.updateMany({ where: { id, status: <expected> } }) for atomic state transitions. Concurrent conflicting requests receive 409 Conflict.

13. Formal Verification Results

13.1 Certora Prover

Key rules verified:

• feeIs2PercentRule — PLATFORM_FEE_BPS == 200
• feeCalculationCorrect — Math matches specification for all inputs
• completionPointsConstantRule — COMPLETION_POINTS == 1
• abandonmentPenaltyConstantRule — ABANDONMENT_PENALTY == -5
• tierBoundariesRule — All 11 score-to-max-job tiers correct
• resolverRoleConstantRule — Role hash is constant and non-zero
• defaultAdminRoleZeroRule — Admin role is 0x00 (OpenZeppelin standard)
• Status transition rules, access control rules, split validation rules

13.2 Halmos Symbolic Execution

6 Timeouts Explained: All 6 timeouts involve nonlinear uint256 arithmetic (multiplication and division with large symbolic inputs). This is an inherent SMT solver limitation, not a property violation. Attempted mitigations:

• Extended timeout from 120s to 300s: same results
• Alternative solvers (bitwuzla, yices): same or worse
• Tightened bounds to $1T USDC range: same timeouts

Timed-out proofs:

1. check_noOverflowOnFee (Score) — amount * 200 / 10000
2. check_feeLessThanAmount (Escrow) — fee <= amount
3. check_fullBuyerRefund (Escrow) — Refund calculation
4. check_lockedIs98Percent (Escrow) — locked == amount - fee
5. check_noOverflowOnFee (Escrow) — Fee overflow check
6. check_noOverflowOnSplit (Escrow) — Split calculation

Assessment: These same properties are independently verified by Certora Prover (different solving approach) and by 160K+ fuzz iterations with zero failures.

14. Test Coverage Summary

Echidna Note: Echidna 2.3.1 cannot deploy UUPS proxy constructors (exceeds EVM gas/code-size limits). This is a known tool limitation. Coverage is fully compensated by Medusa (138 parallel fuzz tests) and Foundry (16 tests @ 10K runs).

Total fuzz iterations (all-time): 82.6M+

15. Known Issues and Residual Risk

15.1 Acknowledged Risks

15.2 Recommendations

1. Add TimelockController: UUPS upgrades are currently instant. A 24-48 hour timelock would give users time to exit before a malicious upgrade could take effect.
2. External Audit: This report represents an internal audit. Before the platform holds significant TVL, an external audit by a recognized firm (Trail of Bits, OpenZeppelin, Spearbit) is recommended.
3. Monitoring: Implement real-time alerts for large escrow creation (>$10K), any adjustScore call, emergency pauses, and role changes.
4. Resolver Hardening: When the AI dispute resolver is built, wrap evidence in XML delimiters in the prompt and validate resolver output to the enum {BuyerRefund, SellerPaid, Split:N} before on-chain submission.

16. Attestation

This audit was conducted internally by the Abba Baba engineering team, not by an external auditing firm.

Determination: Based on 19 Certora formal rules re-verified post-CEI-refactor, 60/64 Halmos symbolic proofs, 137 Medusa fuzz invariants, 160K+ Foundry fuzz iterations, 95 Hardhat unit tests, zero open smart contract findings, and 47/47 platform security findings fixed (39 pre-mainnet + 8 post-mainnet staging) — the V2 system is safe to operate on Base Mainnet.

Recommendation: Engage an external auditing firm before the platform accumulates significant total value locked (TVL). The internal audit provides strong confidence but cannot substitute for independent third-party review.

Report generated March 1, 2026. Commit 75a9095 on main branch.