Tracks and rules.
PClub x EF: Privacy Infrastructure & Confidential Systems. Pick one track. Each is a theme, not a fixed problem, so scope your project to your team's level. Every track has an accessible entry point and room to go as deep as you want.
The token and network
Network: All projects must be deployed on the Base Sepolia Testnet (chain id 84532).
The token, $PLUMBUS. Every submission must use $PLUMBUS, the shared test asset for this buildathon, as its on-chain asset. It lives on Base Sepolia at 0x18a0Ea0e27e906097d459E57a32dB07B7071c5F5 and is worth nothing. It is purely for building.
Get it: the faucet at https://buildaplumbus.pclub.in/ gives you both Base Sepolia gas and $PLUMBUS. Backup gas only (Base Sepolia ETH): https://docs.base.org/chain/network-faucets.
Note: Base Sepolia gas is Base Sepolia ETH, which is not the same as L1 Ethereum Sepolia ETH. An L1 Sepolia faucet will not fund transactions here.
Track 1 AI Agents × DeFi
Build an autonomous agent that trades, manages risk, or allocates capital on-chain, wrapped in the guardrails, policy layers, or verifiable decision-making that keep a fast, fallible agent inside the bounds its owner sets. The point isn't a clever agent; it's that even a broken, adversarial, or compromised one can never exceed its mandate. Show how AI can act on-chain without being trusted with unchecked control over funds.
Objective: Build the layer between the agent and the money: the mechanism that decides what the agent is allowed to do, enforced on-chain. Your agent proposes actions (swaps, lending, rebalancing, liquidity); your policy layer approves or rejects them against owner-set rules; $PLUMBUS is the capital at stake. The interesting engineering is the enforcement, not the agent.
How AI fits (read this): The "agent" is just anything that proposes an action: a hardcoded rule, a short script, or a single LLM API call (market state in, suggested trade out; about 20 lines, no framework, no training, no harness). AI is optional but encouraged, and it's the thing being constrained, not the thing being graded. Whether the agent is LLM-driven or a one-line if, your guardrail has to contain it. The strongest entries reach for a real LLM precisely because it can misbehave in ways you didn't script. See the win condition.
Example ideas (accessible to ambitious)
- A non-custodial vault where an agent can only trade within an owner-signed mandate: max position size, whitelisted tokens, spend rate.
- A risk engine that computes exposure/drawdown limits and vetoes any trade that would breach them, enforced on-chain.
- A signal-follower that routes every action through a policy contract anyone can audit.
- A "prove-then-act" agent that attaches a checkable justification or ZK proof to each trade, so decisions are verifiable without trusting the model.
- An LLM agent you deliberately attack, prompt-injecting it into "send the whole pool to the attacker", while your guardrail blocks the drain on-chain.
What you submit (minimum)
A policy/vault contract deployed on Base Sepolia that holds $PLUMBUS and enforces at least one owner-set rule; an agent (script, rule, or LLM call) that acts through it; and a demo showing one action allowed and one action blocked. That's the floor: no AI, ML, or framework is required to clear it.
What good looks like
The agent can do something useful, but more importantly it can't do something catastrophic. Even when broken, compromised, or adversarial, it stays inside its mandate. Bonus signal: an autonomous or LLM-driven agent whose misbehavior your guardrail provably contains (a live prompt-injection blocked on-chain is the demo to beat), deterministic or verifiable enforcement, a clean split between "decide" and "execute," and an honest trust boundary, where the agent never holds the keys to the pool.
Track 2 Zero-Knowledge Finance
Build applications that use ZK proofs to shield financial state: private balances, confidential transfers, verifiable computation, or provable solvency, without exposing the underlying data. Demonstrate how cryptographic soundness can replace trust in on-chain finance.
Objective: Prove financial facts without revealing the numbers behind them. Write circuits or use a ZK toolchain to prove statements like "I hold enough balance," "this transfer is valid," or "these reserves cover these liabilities," and verify them on-chain. Start from an existing circuit template; you do not need to invent a proof system.
Example ideas (accessible to ambitious)
- Proof-of-solvency / proof-of-reserves: prove total reserves ≥ liabilities without revealing any individual balance. A great first circuit.
- A private access gate or airdrop: prove you're on an allowlist (Merkle membership) without revealing which member you are.
- A shielded pool for $PLUMBUS: deposit, then withdraw to a fresh address by proving membership plus a nullifier. This is unlinkability of amounts and pool state via ZK, as opposed to Track 3's identity-level unlinkability.
- Confidential transfers: hide amounts while proving value is conserved (inputs = outputs), with range proofs that block overflow tricks.
- Build a circuit and demonstrate how an omitted constraint would let someone forge a proof, a concrete lesson in why soundness matters.
What you submit (minimum)
A working ZK circuit built from an existing template (Circom or Noir) with its verifier deployed on Base Sepolia, proving one financial statement about $PLUMBUS, for example proof-of-solvency (reserves ≥ liabilities) or Merkle-membership access. The demo must show a valid proof verifying on-chain and an invalid input failing. That's the floor: you don't need a full shielded pool or confidential-transfer system to clear it.
What good looks like
Honest proofs always verify (completeness) and false ones never do (soundness). A strong submission can defend its soundness argument, not just demo the happy path. Bonus signal: a working on-chain verifier, a reasonable constraint count / proving time, and clarity about exactly what the circuit does and does not prove.
Track 3 Stealth Payments & Account Abstraction
Build with ERC-4337 and stealth addresses to decouple a user's identity and intent from on-chain execution. Create private payments, unlinkable transfers, or intent-based flows that stay confidential while remaining fully on-chain.
Objective: Separate who is acting and what they intend from how the action executes. This involves smart accounts (ERC-4337) that abstract away the signer, stealth addresses that make a recipient unlinkable, and intent-based flows. The theme is privacy and abstraction at the account layer, which is distinct from the balance-layer focus of Track 2.
Example ideas (accessible to ambitious)
- A stealth-address payment tool: send funds to a recipient's published stealth meta-address so an outside observer can't link the payment to them.
- A commit-reveal withdrawal: hide the intent of a withdrawal until it's final (an intent-hiding pattern; note Base Sepolia uses a single sequencer, so this is about concealing intent, not mempool frontrunning).
- A smart account (4337) with custom validation: social recovery, spending limits, session keys, or gas paid in a token via a paymaster.
- An intent-based flow: a user signs "I want X," and a solver or bundler executes it; the user never broadcasts the revealing transaction themselves.
- An end-to-end private payment system combining stealth addresses and account abstraction, so both sender identity and recipient link stay hidden.
What you submit (minimum)
One working flow on Base Sepolia that moves $PLUMBUS while breaking the link between identity/intent and execution. Minimum is either a stealth-address send (ERC-5564) or a smart-account (ERC-4337) action that abstracts the signer. The demo must show that an observer can't link sender to receiver, or that intent is decoupled from execution. That's the floor: you don't need an end-to-end stealth-plus-AA system to clear it.
What good looks like
An outside observer genuinely cannot link parties or read intent. A strong submission survives attempts to deanonymize it. Bonus points for correct 4337 validation with no bypasses, a clean intent/execution split, and use of established standards like ERC-4337 and ERC-5564.
Submission requirements
- Fill the Team registration form: https://forms.gle/rj4Mk8K3UyTTfw8d8
- Fill the submission form: https://forms.gle/SnZ7Au4LxjtT3hQ2A
- GitHub repo link
- Live working link: a hosted demo, or a link to your verified contracts on Basescan plus a runnable script
- 1 demo video: a demo of the actual project working end to end
Timeline
- Task launch: August 20, 2026
- Deadline: August 22, 2026, 11:59 PM