SDK

Build a hook, a companion, or both as a pair

Write a hook or a companion with your own AI coding agent: a hook that runs on every trade, a companion that spends the companion fee, or both as a pair. Deploy it yourself on the open standard, or submit its source to the Workshop: Mintvelocity checks it, builds it and deploys it, and you can earn a share of every launch someone else makes with it.

Two routes

Your own: The standard is open: write a custom hook against the hook crate, deploy it yourself, make it immutable, and put it on a mint of your own, a pool of your own, or a launch on Mintvelocity from a config you make (prepared for the mint with templateHook.prepare, made with buildCreateConfig; the SDK’s README walks the whole terminal flow). A companion the same way: deploy the script, make it immutable, and launch with it through the SDK or the API. The one rule, the programs’: a hook or a script that runs here is immutable, behind the public hook timelock (3 days or more), or upgradeable only by Mintvelocity. Such a program is not read by Mintvelocity: the token shows it as a custom hook written by its creator, with who can upgrade it and no reading. Unless you ask for the reading: submit its source with the program’s address on the same submit page, and once Mintvelocity’s build of your source matches the code on chain, its reading shows wherever the program is used.
The Workshop: You submit the source, never a deploy. Mintvelocity checks it, approves it and deploys it under its own upgrade key; you pay what the deploy costs. It is listed, launchers pick it on the launch page, the site shows Mintvelocity’s reading of it (its rules as exact rows, the most it takes, what to watch), and you earn the share you choose of every launch someone else makes with it: a hook’s builder 0% to 50% of the creator fee, in 5% steps; a companion’s or a pair’s 50% of the launcher’s part of the creator fee, or nothing.

What you can build

A custom hook on the trades: Runs on every transfer of the token - a buy is a transfer out of the pool, a sell one into it. It can take a cut, keep state in each holding, refuse a transfer. It never gets anyone’s signature and calls no other program: the token program applies its answer, never more than the amount.
A companion: Runs on a timer, every 10 s to 1 day, on the companion program, on chain: it holds the launch’s companion fee as a pot and calls your code. It can spend the pot the companion fee fills: market making, buybacks, games. The companion program holds the funds: your code spends the pot and nothing else, leaves the dev’s tokens alone, and never gets anyone’s signature but the companion address’s.
Both, as a pair: The hook on every transfer, the companion on the timer. One item in the Workshop, one approval, one config. The hook takes a cut, keeps a score or funds the pot; the companion pays from the pot, filled by the companion fee, by the hook, or both. The hook records, the companion reads and pays; neither reaches the other’s code. The config requires both, so a launch gets both or neither.

The Workshop takes hooks, companions, and both as a pair. It takes no game drawn at random: a draw needs an oracle the companion pays for, so that is the built-in Jackpot’s, on Mintvelocity’s own lottery hook.

A pair: a hook and its companion as one

A hook on the trades and a companion on the pot, as one. They talk one way, hook to companion. The hook writes per holder, the 64 bytes of hook data in each holding, answered from before_transfer and written by the token program with the balances; per mint, its own state at ["state", mint]. The aggregate goes in the state (a total, a last buyer, the period), the per-holder facts in the hook data. The companion reads: in its step it asks for the hook’s state and the holdings it pays (its keeper.json says which ones the keeper brings), verifies each against its hook data, pays from the pot in SOL, and keeps what it paid in its own state so nothing is paid twice. It can never write hook data; the hook can never pay. No randomness: a step has no payer for an oracle, and a slot or a clock a trader can time is not random. A pair pays by what the hook recorded: the last buyer, the longest holder, who is down. One address: the config made from a pair names the hook and requires the companion.

Four patterns

A token tax that funds the pot: The hook cuts whale trades in tokens into the companion address’s holding; sends are free; each holding’s hook data keeps the epoch it was last paid in. The companion sells what the hook collected into the pot and pays every holder under the whale line once an epoch, in SOL to their wallet. Ships the hook’s src/lib.rs, the companion’s src/lib.rs and its keeper.json.
A score and a game: The hook writes each holder’s score into its hook data (held since when, what was bought, a streak) and the aggregate into its state. The companion pays the leaders from the pot the companion fee fills, once a period, and marks who it paid. Ships both src/lib.rs and a keeper.json that filters holdings on the score’s field.
A SOL cut: The hook implements quote_cut, the launchpad’s callback, and ships hook.json with its caps (1 to 10% of a buy’s SOL, 0 to 10% of a sell’s); the launchpad takes the cut as the hook’s own fee, on top of the launch’s, and on a pair it lands whole in the pot.
A payout through the companion: Lossback’s path. The hook keeps a record in the hook data (an entry price, what was paid) and has record_payout, which only the companion’s payout authority may sign. The companion’s step answers a PayoutAnswer naming holdings among its accounts; the companion pays each owner from the pot within the terms and has the hook record it. Ships both src/lib.rs and a keeper.json with payouts: true, payTo: owner.

The template and its rules

A hook is one Anchor program on Mintvelocity’s template. You write its Rust files under src/; the Cargo.toml and the crates are the builder’s, so a hook adds no crate of its own. The rules, checked on your files before anything else:

Its files: Rust files under src/ with lower-case names: at most 8 files and 120 kB in all. src/lib.rs is the program.
No calls: It calls no other program. It acts only through its answers to the token program.
No SOL: It moves no SOL, and closes or resizes no account.
Plain Rust: No unsafe code, no inline assembly, no macros of its own, and nothing read from the build machine (include_*!, env!, option_env!, #[path]).
Its id: One declare_id! and one #[program] module. The builder writes the program id Mintvelocity reserves for it.
prepare: The standard one: no arguments; accounts payer, mint, state at ["state", mint], registry, system program. The launch sends it for each new mint.
Its registry: The extra accounts every callback gets: only the hook’s own and the mint’s, at most 4, written once by prepare.
Beside src/: keeper.json for a companion that pays holders: which holdings each step brings and how often a step runs. hook.json for a hook with a SOL cut: its caps. Both are checked at submission and bound by the approval.

A companion builds on a template of its own, since it trades on the DEX and so can’t keep the rule against calling other programs. Its starter is public in the SDK’s repository, starters/script.

Give your agent the brief: open an empty folder in Claude Code, Cursor or any coding agent and paste the brief for what you are building. It holds the template, every rule the checks hold it to and how to test it, and it tells your agent never to deploy anything: on this route, Mintvelocity deploys.