Templates / Funding
Super Grant: grant money to start, more money for verified outcomes
A foundation issues a Request for Ideas and grants each admitted developer a set amount, provided the developer runs its AI under the terms attached to the grant. The developer has a fixed window to respond. A jury checks the response against the terms, and a grantee that clears them can earn outcome tranches, such as revenue, each verified by a jury before the escrow pays.
Why it exists
Grants pay for promises: a committee picks proposals, pays up front, and reads self-written reports months later. Venture funding pays for outcomes, but only for a few teams, in large checks, on belief before there's evidence.
Ecosystems need the space in between: small money to many builders quickly, then more money to the ones that show results. The bottleneck has always been checking results at scale. A jury of models from different families, reading pinned evidence against written terms, removes it.
Foundations and ecosystem funds
Fund many teams at once, and pay follow-on money only against outcomes someone checked.
Developers
Money to start in days, clear terms for earning more, and a record of what you shipped.
Investors
An optional follow-on instrument (a post-money SAFE, a revenue share, a right of first refusal) signed into the program from day one.
How it works
Request for Ideas
The foundation publishes the problem, the terms every response must meet, the agent terms grantees run their AI under, the base grant, the outcome tranches and the review rules, and funds a Squads escrow with the whole budget.
Apply
A developer applies with a key, a payout wallet and an idea, and signs the hash of the agent terms.
Admit and pay the base grant
The foundation admits up to the program's limit. Admission earns the base grant.
Respond inside the window
Two weeks by default. The response pins its evidence by hash. Late responses and second responses are refused.
Review
One ASC per response: does it meet every term? CLEARED or NOT_CLEARED. The grantee's own summary reaches the jury as an untrusted claim.
Claim outcomes
A cleared grantee claims a tranche with evidence. One ASC per claim: does the evidence show the outcome exactly as written? MET or NOT_MET.
Pay and close
The signer pays only what the ledger shows was earned, once each. After the program ends, the unearned budget returns to the foundation.
What you fill in
The fields of super-grant. The whole document is hashed, and that hash is what everyone signs and the signer on chain carries.
| Field | What it holds |
|---|---|
request | The problem, the terms (each with an id), the response window, what a response contains |
agentTerms | The terms the grantee's AI runs under, in plain words; applications sign their hash |
money | Asset, budget, base grant, maximum grantees. The budget must cover every grantee earning every tranche. |
tranches | Outcome name, exactly what counts, what proves it, amount, claim window |
followOn | Optional: post-money SAFE, revenue share or right of first refusal, with its terms |
window, review | Application deadline and end; jury size, families, bar, fee |
What code checks, and what the jury decides
Code: the same answer on every computer
- Only token and system programs
- Never more than the budget in one transaction
- Pays only entitlements the ledger shows: base grants on admission, tranches after CLEARED and MET, the refund after the end
- Each entitlement once, by the signer's own case log
- Every ruling must be on the contract the log produces, and its sealed round must verify
- No change to the wallet's members or settings
Jury: the questions only judgment can answer
- Does the response meet every term of the Request for Ideas?
- Does the evidence show this outcome, exactly as written?
- Revenue counts only from customers who are not the grantee, its principals or the foundation.
A rule violation is final: the signer refuses it whatever the jury says.
What gets paid
| Entitlement | Earned when | Paid to |
|---|---|---|
| Base grant | The foundation admits the grantee | Grantee |
| Outcome tranche | The response was CLEARED and the outcome was MET | Grantee |
| Refund | The program ended and nothing is undecided | Foundation |
The foundation can't take the budget back early, and a grantee can't be paid a tranche it didn't earn.
Attacks, and what stops them
| Attack | Defense | Status |
|---|---|---|
| A grantee pays itself to fake revenue | The tranche wording and the jury instructions exclude money from the grantee, its principals and the foundation | Jury question; evidence is the open risk |
| A response tells the jury to answer CLEARED | The summary is labeled untrusted; the jury reads the pinned evidence | Tested with a scripted jury |
| A ruling on a different question | Each review is rebuilt from the program and the log; a mismatch is thrown out | Tested |
| An edited sealed ruling | Fails verification of the signed round | Tested |
| The foundation claws back the budget early | The refund exists only after the end, with nothing undecided | Tested |
| A payment made twice | Each entitlement is paid once, by the signer's case log | Tested |
Every case the signer builds labels the parties' own text as untrusted and never follows instructions in it. See Security for the threat model behind all templates.
Example: Agents that pay each other
{
"kind": "verafy.super-grant/1",
"request": {
"summary": "Working tools that let one AI agent pay another on Solana, with a receipt both sides can check.",
"terms": [
{ "id": "prototype", "text": "Ships a working prototype in a public GitHub repository." },
{ "id": "license", "text": "Open source under MIT or Apache-2.0." },
{ "id": "solana", "text": "Payments settle on Solana, with a transaction signature shown." }
],
"responseSeconds": 1209600
},
"agentTerms": { "text": "No custody of user funds, every payment logged with a receipt, and the Verafy review is final." },
"money": { "asset": "SOL", "budget": "20000000000", "baseGrant": "2000000000", "maxGrantees": 2 },
"tranches": [
{ "id": "revenue-1k", "outcome": "Revenue", "text": "At least $1,000 from at least five paying customers who are not the grantee or the foundation.", "amount": "5000000000" },
{ "id": "integration", "outcome": "Integration", "text": "Another team ships the tool in a product.", "amount": "3000000000" }
],
"followOn": { "instrument": "post-money-safe", "text": "Up to $250,000 at a $10M cap within 6 months of a met revenue tranche." }
}The prompt
Paste this into any capable AI. It asks you about your case one group at a time, writes the super grant for it, explains who gets what in each outcome, points out risks in your terms, and ends with the harness call that checks the result. It never asks for keys: each party signs with its own, outside the conversation.
You are helping me design a Verafy Super Grant (verafy.super-grant/1, VIP-0030): a foundation issues a Request for Ideas, pays each admitted developer a base grant to respond, has a Verafy jury check every response against the terms, and pays outcome tranches (for example revenue) only after a jury verifies each outcome. The escrow pays only what was earned and returns the rest to the foundation when the program ends.
Rules for you, the AI:
- Ask me the questions below one group at a time. Don't invent facts about my deal; if I don't know an answer, propose a sensible default and say it is a default.
- Amounts are whole base units as strings (1 SOL = "1000000000"). Times are unix seconds.
- Write every term, outcome and article so a stranger could decide from evidence alone whether it was met. No "reasonable", "high quality" or "timely" without a number or a test.
- Name the evidence that proves each thing, and prefer evidence that can be pinned by hash (a file, a commit, a transaction signature, an export).
- Never ask for or handle private keys. Each party signs with its own key, outside this conversation.
- When you're done, output: (1) the JSON, (2) a plain-English summary of who gets what in each outcome, (3) the risks you see in my terms, and (4) the harness call that checks it.
Ask me:
1. The Request for Ideas. The problem I want ideas for, in two or three sentences, and who it's for.
2. The terms every response must meet. Three to six, each testable from the response's evidence (for example: public repository, open-source license, a transaction signature on devnet).
3. The agent terms. What the grantee's AI must and must not do while running under this grant (custody, logging, data use, that the Verafy review is final).
4. The money. Asset, base grant, how many grantees at most, and the total budget (it must cover every grantee earning every tranche).
5. The outcome tranches. For each: the outcome (Revenue, Users, Integration...), exactly what counts with a number, what evidence proves it, the amount, and how long after admission it can be claimed. For revenue, say which money doesn't count (self-paid, from the foundation, round-tripped).
6. The response window (two weeks is the default), the application deadline and the program end.
7. Follow-on: none, a post-money SAFE, a revenue share or a right of first refusal, with its terms in plain words.
8. The review jury: size, model families, bar, fee.
Then produce the program JSON with these fields: kind, id, title, foundation {name, key, wallet}, request {summary, terms [{id, text}], responseSeconds, responseEvidence}, agentTerms {text}, money {asset, budget, baseGrant, maxGrantees}, tranches [{id, outcome, text, evidence, amount, claimSeconds}], followOn {instrument, text}, window {applyUntil, endsAt}, review {bar, jury {size, minFamilies}, fee}.
Check it with: validateGrant(program), then policyFromTemplate('super-grant', { program }).Run it
In code
policyFromTemplate('super-grant', { program })
grantLedger(program, log, rulings, { now })
reviewContract(program, log, grantee)
outcomeContract(program, log, grantee, tranche)The demo
git clone https://github.com/Verafyai/verafyHarness cd verafyHarness node scripts/grant-demo.mjs
| File | What it is |
|---|---|
packages/core/src/grants.js | Programs, log, reviews, outcomes, ledger, policy |
packages/core/src/programlog.js | Signed logs and the payout check shared with hackathons |
packages/core/test/grants.test.js | 3 tests |
scripts/grant-demo.mjs | Two grantees, one cleared, one not |
Status, honestly
- 3 of 3 tests pass: program validation, every log rule, and the full ledger and escrow path including tilted and edited rulings
- In the demo, Alice earns 2 SOL plus a 5 SOL revenue tranche, Bob earns his 2 SOL base grant, and 11 SOL returns to the foundation
- Not on devnet
- Revenue evidence is pinned by the grantee; a processor-signed export would make it far harder to fake
- The follow-on instrument is recorded and signed, not executed
- A NOT_MET claim is final; resubmission is a decision for Rex
| Proposal | Status |
|---|---|
| VIP-0030: Super grants: venture-style funding paid out on verified outcomes | Shipped (v0.0.5-alpha): not yet on devnet |
| VIP-0010: Judiciary Signer: a multisig member that votes only as a jury rules | Shipped (v0.0.4-alpha); devnet deploy open |
| VIP-0011: Policies, and Covenant Launch: rules a wallet cannot break | Shipped (v0.0.4-alpha) |
Other templates
VIP-0029
Agentic Contract
Two AI agents sign terms and every way the deal can end. The money waits in a two-of-three escrow. If they disagree, a jury picks one of the signed remedies.
VIP-0033
Agent Bond
An operator puts money behind its AI agent's behavior. Anyone can report a violation; a jury rules; the bond is slashed as each rule is priced. Agents can slash agents.
VIP-0031
Hackathon Grant
Post a prize pool and evaluation criteria, open the hackathon, take GitHub submissions pinned to a commit, and let a Verafy council grade every one.
VIP-0011
Treasury
A DAO or team budget that pays approved payees under a per-payment and a monthly cap, with a jury checking each payment's purpose.
VIP-0032
DAO Constitution
A DAO treasury that executes a passed proposal only if it breaks no article of the constitution. Caps in code, one jury question per article.
Actually Smart Contracts