How It Works
BERT turns USDC commitments into transparent builder funding on Arc.
The protocol is a programmable capital allocation system: builders post a USDC author bond and declare a minimum viable grant, contributors make refundable USDC pledges to one proposal, and only a viable winner unlocks milestone-based releases controlled by its own backers.
Proposal Deposit
50 USDC
Minimum author commitment to submit a live idea into the registry.
Vote Commitment
10 USDC
Minimum onchain vote amount required to support an idea in an active round.
Release Rail
20 / 40 / 40
Initial claim followed by two backer-approved milestone releases.
Verified Voting
PoP + 10k cap
Arc Testnet uses Demo PoP; mainnet will require World ID. Each wallet is capped at 10,000 USDC per idea.
Funding flow
BERT coordinates one continuous funding path. Proposal bonds filter out spam, a 14-day round records idea-specific pledges, settlement refunds losing paths, and a viable winner moves into backer-controlled milestone releases. Capital is never silently redirected from one idea to another.
1. Builder submits an idea
A builder creates an idea in IdeaRegistry, posts at least a 50 USDC author bond, declares a minimum net funding target, and commits an immutable milestone-plan hash and URI before the idea can enter a V2.3 round.
2. A voting round opens
VotingSystem starts a round only after 30 eligible V2.3 ideas are queued. The round stays open for 14 days, so participants have time to compare scope, targets, and the committed delivery plan.
3. Voters activate verification first
On Arc Testnet, a wallet activates clearly labelled Demo verification and finalizes its signed payload onchain through PoPVerifierUpgradeable. Mainnet will replace this test-only path with production World ID proof-of-personhood.
4. USDC pledges stay idea-specific
Every valid pledge is held as escrow for its selected idea in FundingPool. The per-wallet 10,000 USDC cap reduces single-wallet dominance; losing pledges never fund another idea and become refundable after settlement.
5. Winner enters grant execution
After settlement, only the highest-funded viable idea enters GrantManager. Viability requires its declared post-fee target and at least three distinct winning backers. If no idea qualifies, pledges remain refundable.
6. Milestones unlock funding
The author claims 20%, then submits proof for each 40% stage. Only the winning pledgers can vote on proof: 40% pledge-weight quorum, two-thirds approval of participating weight, and three approving verified backers are required.
Human verification flow
BERT still uses USDC-weighted voting, but protected voting requires an onchain verification record before that capital can be used. Arc Testnet uses Demo verification to test this gate without making a claim about the wallet's real-world identity.
On Arc Testnet, the frontend requests a clearly labelled Demo payload and the wallet submits it toPoPVerifierUpgradeable. This exercises the real onchain access gate but does not prove personhood. On mainnet, the frontend will open World ID; the backend will verify the proof and bind its unique nullifier to one wallet before issuing the same kind of onchain payload.
The current verification window is 14 days. After that, the wallet simply refreshes its verification and continues using the same address.
Why the 10,000 USDC cap exists
In production, human verification helps against Sybil voting, but it does not limit how much influence a single verified wallet can concentrate on one idea. The per-wallet cap closes that second gap.
BERT now limits each wallet to 10,000 USDC per idea. Large participants can still support the protocol, but one wallet cannot unilaterally overpower an idea round by sending an outsized vote into a single target.
This keeps the system practical: capital still matters, but the protocol now asks for both production World ID verification and bounded per-wallet influence before treasury allocation can happen.
Milestone release logic
Winning a round does not trigger a single lump-sum payout. GrantManager releases funding in a staged sequence so capital follows proof of execution rather than hype.
The V2.3 rail is 20% / 40% / 40%. The builder claims the initial 20%, then submits proof for the in-process and completion stages. The winning pledge cohort has 14 days to review each proof. A release requires 40% of total winning pledge weight to participate, two-thirds approval of that participating weight, and three approving verified backers.
A vote remains open through its full review window, so reaching quorum never closes out other backers. If there is no quorum, a one-time 7-day grace period begins. Silence never releases capital: an unresolved review, missed author deadline, or second failed review makes all unreleased escrow pull-refundable pro rata to the winning pledgers.
Operator checklist
- USDC commitments use explicit allowance checks before protocol actions execute.
- Round voting permits one pledge per wallet per round and blocks an author from pledging to their own idea.
- Protected voting requires an active onchain verification record; Arc Testnet uses Demo PoP and mainnet will use World ID.
- Per-idea vote size is capped at 10,000 USDC per wallet to reduce single-wallet control.
- New V2.3 grants use a 20 / 40 / 40 rail; unreleased escrow is refundable if the backer-controlled path fails.
- Pause controls remain available for incident handling and controlled rollout.
- Only the winning pledge cohort can validate V2.3 proof; the author has no milestone vote.
BERT V3.1 Community Layer
A self-contained Community where capital release remains reviewable.
V3.1 adds stake-backed Community governance without replacing the V2 builder-grant rail above. Each Community receives an independent CommunityHub for roles, proposals, voting, active-time clock, and governance requests, plus a paired CommunityTreasury for escrow, execution capital, Validator rewards, failed-plan refunds, and withdrawal approvals. A settled winner starts an execution plan: the configured administration recipient receives 20%, then only the wallets that supported that winner review proof for the final 40% / 40%. Community-specific decisions remain local; configured protocol-reserve flows remain visible to the broader BERT FundingPool.
1. Configure
A creator sets immutable entry stake, proposal bond, vote floor, validator thresholds, Admin quorum, the Administration execution wallet, and every local timing window including proof and review windows. The wallet is not a second Treasury: it receives only approved execution tranches.
2. Activate
Factory reserves the Treasury, deploys the matching Hub, verifies the pair, and indexes a numeric Community ID with Hub, Treasury, creator, and metadata.
3. Govern & review
Participants join locally, submit one of four proposal modes, validate Member ideas, vote with USDC, and winning supporters approve or reject execution proof before later capital is released.
Roles are local
One Community, clear responsibility boundaries.
V3 roles are not BERT V2 roles. A wallet’s permissions are evaluated separately inside each Community. Active governance roles are deliberately mutually exclusive, so the same wallet cannot be both the validator and the Member whose proposal it is reviewing.
Member
Joins with a Community-specific entry stake, creates Member proposals, and participates in voting. Exit requires a cooldown, cleared vote locks, and no active Member proposal.
Validator
Reviews Member proposals and earns epoch rewards only for sufficient onchain activity. Validator rewards do not accrue from Admin-originated proposals because no validation work was required.
Admin
Creates Admin proposals, organizes Slate Rounds, manages the roster through quorum-protected requests, and manages execution withdrawals without unilateral access to Community funds.
Four proposal paths
Choose a direct decision or a competitive round.
Admin Binary
An Admin proposes one decision and Members stake YES or NO. There is no validator review because the proposal is Administrator-originated. A YES settlement routes the voting capital to local execution.
Member Binary
A Member posts the configured bond, Validators approve or reject during the validation window, and only an approved proposal opens for Member voting. The settled path can allocate execution, validator rewards, and protocol reserve according to the Community configuration.
Admin Slate
Admins prepare several eligible options for a support-only round. Members select one proposal with one stake-backed round vote. The highest onchain total wins; a tie follows the deterministic contract proposal order.
Member Slate
Member ideas first earn validator approval, then an Admin builds a slate from contract-eligible proposals. The round picks one winning idea while keeping the selection rule and settlement history onchain.
The interface only offers proposal and round actions that the current wallet can perform according to the Hub. Contract state decides eligibility, validation, settlement, and every USDC movement.
Capital lifecycle
Every bucket has a distinct purpose.
Membership stake stays locked to an active Member and returns only through the guarded exit flow. It is not a discretionary treasury balance.
Vote escrow is held until a binary proposal or Slate Round settles. When NO wins a binary vote, eligible NO voters claim their own stake once, less the Community's configured NO fee.
Execution treasury holds the local capital available for the Community to implement approved decisions. It can leave only through a request, the configured multi-Admin quorum, and execution.
Validator rewards accrue only from qualifying Member proposal flows, are finalized after an epoch ends, and are claimed individually by Validators who met the onchain activity threshold.
Protocol reserve is routed through the V2 FundingPool integration where the deployed Community settlement rule requires it, preserving V2 reserve accounting.
Time, pause, and treasury safety
A Community clock prevents silent deadlines during incidents.
Validation, binary voting, Slate voting, reward epochs, exit cooldowns, and quorum-request expiry are measured in active Community time. A pause stops the Community clock; resume continues only the time remaining.
Pause blocks governance-sensitive paths such as new proposals, votes, validation progression, and new execution withdrawals. It does not let the frontend bypass settled onchain claim rules.
Execution funds are not released by a single arbitrary click. The Community Treasury retains custody, while a settled winner creates an immutable 20 / 40 / 40 plan for the configured Administration execution wallet. Later tranches require sealed winning-supporter quorum and approval. Separate Treasury withdrawals additionally use the configured Admin quorum.
Adding or removing Admins, Validators, pausing, resuming, archiving, and cancelling a withdrawal are also quorum-protected requests. This prevents unilateral roster capture from becoming a treasury takeover.
Testing versus production
Use the same contracts, with a clearly separate accelerated demo Community.
Production-style Communities should use the intended day-scale validation, voting, exit, and reward windows. For a hackathon demo or local walkthrough, deploy a separately labelled Community whose proposal, validation, voting and reward windows use minute-scale settings. Milestone review intentionally keeps its one-day contract minimum; a local Hardhat E2E environment advances chain time instead of weakening the production rule.
Open Community Layer