Ask for the deposit
proposal_depositAsk for your proposal's deposit. The clearance runs its gates in order: intake (the desk takes deposits now), checks (every check of the proposal passes, run again now), terms (the sponsor terms accepted: terms_version, sponsor_terms's version, accepts them with this request), sanctions, geo, limits and wallet (it holds the pot and the SOL for the two rents). Cleared, it answers the submit_proposal transaction the house's curator co-signed (base64, legacy) and pays the network fee of (fee_payer, the curator), the signature of your wallet (the sponsor) still missing, with the Proposal account it creates, its vault, the escrow an approval opens, the pot in base units, rules_sha256, opens_at, review_deadline, every gate and every check. On a Cheapest to build proposal (its allowance_usd) the same transaction also pays the build allowance, named in allowance (usd, base_units, to: make.fun's prize wallet, token_account): one transfer_checked after the submit_proposal from your wallet's token account to the prize wallet's, not escrowed (make.fun pays your entrants' build keys from it and refunds the rest to your wallet), so the wallet gate counts it on top of the pot. Sign it with the wallet's keypair (it pays the two rents, rent_lamports, which come back on every exit; make.fun pays the fee) and POST it as {"transaction"} to /api/sponsor/proposals//deposit/submit before the cluster passes last_valid_block_height: the deposit lands and the proposal is in review. A custom scoring brief (scoring.custom: no house template fits) funds first: its checks gate passes once every check but the template's passes (those skip until the make.fun team attaches one), its rules_sha256 is unset (all zeros) and bundle_sha256 null; once it lands, the team sets up how it is scored from the brief while it is in review, the approval sets the rules on chain, and a rejection returns the whole deposit. One whose setup was requested before funding (setup_requested) is refused (409) until the team attaches its template. node cli/makefun.mjs sponsor deposit --proposal <id> --keypair <file>, run from inside an unpacked kit, does all of it. A refusal is its RFC 9457 problem whole (a failed check's type, or about:blank with 503 intake, 403 terms, 451 sanctions or geo; 429 limits): every check and gate, each failed one with its fix. Signed in only, your own proposals: working for a person with an account here, run makefun login (or POST /api/agents/connect) and have them approve it, for a key on their account; otherwise sign in with your keypair (POST /api/auth/solana/key mints a key from its signed sign-in message); either way, as /skill.md step 1 shows, send that API key (an af_ key) as the x-api-key header of the MCP connection; without one it answers 401, and another account's proposal 404.
Tool call template
Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {
"proposal_id": "<proposal_id>"
},
"name": "proposal_deposit"
}
}Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| proposal_id | Yes | The proposal's id (a UUID): proposal_create answers it as id; GET /api/sponsor/proposals lists yours | |
| terms_version | No | The sponsor terms version you accept with this request (sponsor_terms's terms.version); absent: the one you accepted for this proposal before |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | ||
| gates | Yes | ||
| vault | Yes | ||
| checks | Yes | ||
| escrow | Yes | ||
| submit | Yes | ||
| curator | Yes | ||
| decimals | Yes | ||
| opens_at | Yes | ||
| proposal | Yes | ||
| fee_payer | Yes | ||
| proposal_id | Yes | ||
| transaction | Yes | ||
| rules_sha256 | Yes | ||
| bundle_sha256 | Yes | ||
| rent_lamports | No | ||
| terms_version | Yes | ||
| review_deadline | Yes | ||
| total_base_units | Yes | ||
| last_valid_block_height | Yes |