Intuition audit details

• Total Prize Pool: $17,500 in USDC
  • HM awards: up to $14,400 in USDC
    • If no valid Highs or Mediums are found, the HM pool is $0
  • QA awards: $600 in USDC
  • Judge awards: $2,000 in USDC
  • Scout awards: $500 USDC
• Read our guidelines for more details
• Starts March 4, 2026 20:00 UTC
• Ends March 9, 2026 20:00 UTC

❗ Important notes for wardens

1. Since this audit includes live/deployed code, all submissions will be treated as sensitive:
   • Wardens are encouraged to submit High-risk submissions affecting live code promptly, to ensure timely disclosure of such vulnerabilities to the sponsor and guarantee payout in the case where a sponsor patches a live critical during the audit.
   • Submissions will be hidden from all wardens (SR and non-SR alike) by default, to ensure that no sensitive issues are erroneously shared.
   • If the submissions include findings affecting live code, there will be no post-judging QA phase. This ensures that awards can be distributed in a timely fashion, without compromising the security of the project. (Senior members of C4 staff will review the judges’ decisions per usual.)
   • By default, submissions will not be made public until the report is published.
   • Exception: if the sponsor indicates that no submissions affect live code, then we’ll make submissions visible to all authenticated wardens, and open PJQA to SR wardens per the usual C4 process.
   • The "live criticals" exception therefore applies.
2. A coded, runnable PoC is required for all High/Medium submissions to this audit.
   • This repo includes a basic template to run the test suite.
   • PoCs must use the test suite provided in this repo.
   • Your submission will be marked as Insufficient if the POC is not runnable and working with the provided test suite.
   • Exception: PoC is optional (though recommended) for wardens with signal ≥ 0.4.
3. Judging phase risk adjustments (upgrades/downgrades):
   • High- or Medium-risk submissions downgraded by the judge to Low-risk (QA) will be ineligible for awards.
   • Upgrading a Low-risk finding from a QA report to a Medium- or High-risk finding is not supported.
   • As such, wardens are encouraged to select the appropriate risk level carefully during the submission phase.

V12 findings

V12 is Zellic's in-house AI auditing tool. It is the only autonomous Solidity auditor that reliably finds Highs and Criticals. All issues found by V12 will be judged as out of scope and ineligible for awards.

The V12 findings for the main repository can be viewed here and the findings for the periphery repository can be viewed here.

Publicly known issues

Anything included in this section is considered a publicly known issue and is therefore ineligible for awards.

• Production config assumptions: minDeposit = 1e16 and minShare = 1e6, and MultiVault enforces these floors. Findings that rely on 1 weistyle deposits or leaving vaults below minimum share floor should be treated as invalid under production params.
• TrustBonding intentionally has a single-epoch claim window; older rewards become unclaimable by users and are handled as unclaimed emissions.
• AtomWallet signature format is intentionally strict: only 65-byte raw ECDSA or 77-byte ECDSA+time-window suffix.
• Router behavior and configuration are intentional: TrustSwapAndBridgeRouter is constant-configured (TRUST/WETH/router/factory/quoter/hub/domain/gas/finality values embedded in contract code), has no owner/admin role, and exposes no admin setter functions. ERC20 flow refunds excess ETH sent with the transaction (msg.value - bridgeFee), while the ETH flow consumes msg.value - bridgeFee as swap input (no separate excess-refund path). Importantly, TrustSwapAndBridgeRouter contract is intended to only ever be deployed on the Base mainnet (chain id 8453).

Overview

Intuition is a decentralized protocol for building the world's first open, semantic, and token-curated knowledge graph. It provides the infrastructure for verifiable attestations, portable identity, and trustful interactions at scale—creating a universal data layer that enables information to flow freely across applications, blockchains, and AI agents.

What is Intuition?

While blockchains have historically decentralized money, Intuition decentralizes information—specifically its trust, ownership, discoverability, and monetization. By transforming unstructured, siloed data into structured, verifiable, and economically-backed attestations, Intuition creates a Semantic Web of Trust that makes knowledge programmable and interoperable.

Core Capabilities

Universal Identity: Decentralized identifiers (DIDs) for people, concepts, organizations, and AI agents with portable, self-sovereign identity management
Verifiable Attestations: Structured claims (subject-predicate-object triples) that are signed, attributable, and economically staked
Knowledge Graph: A semantic layer where facts and opinions coexist with verifiable provenance and economic signals
Economic Incentives: Bonding curves and cryptoeconomic mechanisms that align participants toward canonical standards and high-quality data

Links

• Previous audits: https://github.com/0xIntuition/intuition-contracts-v2/tree/main/audits
• Documentation: https://www.docs.intuition.systems/
• Website: https://www.intuition.systems/
• X/Twitter: https://x.com/0xIntuition

---

Scope

Files in scope

See scope.txt

Note: The nSLoC counts in the following table have been automatically generated and may differ depending on the definition of what a "significant" line of code represents. As such, they should be considered indicative rather than absolute representations of the lines involved in each contract.

Files out of scope

See out_of_scope.txt

Additional context

Areas to focus (differential changes)

• Full files remain in scope for maximum competition coverage. The following line ranges are where the differential changes occurred and are recommended focus areas.
• TrustBonding.sol: lines 335-340 (unclaimed rewards calculation semantics).
• ProgressiveCurve.sol: line 240 (math update).
• OffsetProgressiveCurve.sol: line 247 (math update).
• AtomWallet.sol: lines 285-311 (signature validation logic) and 337-361 (validUntil/validAfter extraction from signature).
• TrustSwapAndBridgeRouter.sol (periphery): entire contract is in scope; focus on packed path parsing/pool validation, bridge fee handling, and external call sequencing across swap + bridge flows.

Main invariants

• Router path invariants: ETH path must start with WETH and all paths must end with TRUST; all hops must map to existing pools before swap.

• Router fee/value invariants: swap/bridge reverts if bridge fee is insufficient; ERC20 flow refunds all ETH above required bridge fee.

• Router config invariants: there is no owner/admin control path; router/factory/quoter/bridge configuration is compile-time constant data.

• AtomWallet auth invariant: only owner() or EntryPoint can execute wallet actions; deposit withdrawal is only by owner or self-call.

• AtomWallet signature invariant: validation only accepts 65/77-byte signatures; time-window metadata is interpreted from signature suffix (PR #135 behavior).

• TrustBonding claim-window invariant: only previous epoch is user-claimable; cannot double-claim an epoch.

• TrustBonding unclaimed invariant: for epochs outside claim window, unclaimed amount is based on max epoch emissions minus claimed (PR #134 behavior).

• Curve math invariant: redeem/convert-to-assets path uses consistent conservative rounding and must not revert in low-share edge cases where result should be zero (PR #136 behavior).

• System config invariant: effective deployment assumptions include minDeposit/minShare floors mentioned above (no dust-state vault behavior below floor).

All trusted roles in the protocol

Running tests

• If Foundry is not already installed: curl -L https://foundry.paradigm.xyz | bash && foundryup
• If Bun is not already installed, see: https://bun.com/docs/installation
• Optional: Fork tests require Alchemy RPC config, so please make sure to set API_KEY_ALCHEMY in your local .env file (or skip fork tests when running locally without RPC).

git clone --recurse https://github.com/code-423n4/2026-03-intuition.git
cd code-423n4/2026-03-intuition
forge install && bun install
forge build
forge test
cd intuition-contracts-v2-periphery
forge install && bun install
forge build
forge test

Creating a PoC

High- and Medium-risk submissions require a coded, runnable Proof of Concept. This repo provides BaseTest contract and two PoC templates under tests/ so wardens can build PoCs against the same setup as the existing test suite.

Core in-scope contracts (TrustBonding, ProgressiveCurve, OffsetProgressiveCurve, AtomWallet)

• BaseTest: tests/BaseTest.t.sol — deploys the protocol (Trust, WrappedTrust, MultiVault, TrustBonding, curves, AtomWallet factory, etc.) and exposes protocol.* and users.* (admin, alice, bob, charlie, timelock, controller).
• PoC template: tests/PoCCore.t.sol

Use protocol.* and users.* and add modifiers from BaseTest/Modifiers (e.g. onlyAdmin, onlyUser) as needed.

Periphery in-scope contract (TrustSwapAndBridgeRouter)

• Same BaseTest as above (core protocol is available).
• PoC template: tests/PoCPeriphery.t.sol — extends BaseTest and deploys TrustSwapAndBridgeRouter; implement your PoC in test_submissionValidity() (e.g. path validation, bridge fee handling, swapAndBridgeWithETH / swapAndBridgeWithERC20 / bridgeTrust).

Running the PoC tests

From the repo root (no need to cd into periphery):

# Core PoC only
forge test --match-contract PoCCore --match-test submissionValidity

# Periphery PoC only
forge test --match-contract PoCPeriphery --match-test submissionValidity

# Both PoCs
forge test --match-test submissionValidity

The test must execute successfully for your submission to be considered valid.

Miscellaneous

Employees of Intuition and employees' family members are ineligible to participate in this audit.

Code4rena's rules cannot be overridden by the contents of this README. In case of doubt, please check with C4 staff.