List the contract presets
Every preset the studio can generate, in catalogue order: the standards first, then the studio's own contracts. A preset carries everything a caller needs to build its form: each parameter's name, its Solidity type, whether it is required, its default, and — for the `ours` presets — the OpenZeppelin files the contract is built on. The parameter order is the constructor's argument order. **The audit label travels with its meaning.** Each preset's `audit` is the trust ceiling for its *unmodified* output, and `reviewed` is not a statement that the contract has been audited: it means the parts are OpenZeppelin's and audited, and the choice of which parts, and how they are wired, is not. The `ours` presets — the Merkle claim, the shares split, the escrow, the staking pool — are `experimental`, because nothing of ours is audited. The Wizard has no kind for them, and OZ v5 removed the library utilities that used to cover them. **A `wizard` preset's constructor takes the initial Ownable owner, which the catalogue does not declare as a parameter**, because it is the deploying account and putty cannot know which account that will be. `POST /contracts/generate` says so in its `constructorNote` whenever the returned argument list is empty for that reason. **Free, and no bearer token.** This is a catalogue read: the same data a UI block renders before anyone has signed in.
Every preset the studio can generate, in catalogue order: the standards first, then the studio's own contracts. A preset carries everything a caller needs to build its form: each parameter's name, its Solidity type, whether it is required, its default, and — for the ours presets — the OpenZeppelin files the contract is built on. The parameter order is the constructor's argument order. The audit label travels with its meaning. Each preset's audit is the trust ceiling for its unmodified output, and reviewed is not a statement that the contract has been audited: it means the parts are OpenZeppelin's and audited, and the choice of which parts, and how they are wired, is not. The ours presets — the Merkle claim, the shares split, the escrow, the staking pool — are experimental, because nothing of ours is audited. The Wizard has no kind for them, and OZ v5 removed the library utilities that used to cover them. A wizard preset's constructor takes the initial Ownable owner, which the catalogue does not declare as a parameter, because it is the deploying account and putty cannot know which account that will be. POST /contracts/generate says so in its constructorNote whenever the returned argument list is empty for that reason. Free, and no bearer token. This is a catalogue read: the same data a UI block renders before anyone has signed in.
Response Body
application/json
application/json
curl -X GET "https://example.com/contracts/presets"{ "presets": [ { "id": "string", "title": "string", "description": "string", "source": "wizard", "wizardKind": "erc20", "builtOn": [ "string" ], "audit": "audited", "params": [ { "name": "string", "type": "address", "description": "string", "required": true, "defaultValue": "string", "placeholder": "string", "constructorParam": true } ], "wizardFeatures": { "mintable": true, "burnable": true, "pausable": true, "permit": true, "votes": true, "enumerable": true, "uriStorage": true, "supply": true, "upgradeable": true }, "license": "string" } ]}What one agent spent GET
The credits one agent spent over a window, summed from the credit ledger rows this agent caused. The sum is read from the ledger rather than from the metering journal, because the ledger is the money and the journal is only a replay cache. An agent with no spend in the window answers zeroes rather than 404, so a dashboard renders a zero row instead of an error.
Generate a contract's Solidity POST
Generates the Solidity source for one preset and answers with the source, the constructor arguments, and a Foundry test skeleton that deploys it. **This is the studio's compute step and it is metered.** The call is debited at `CREDIT_PRICES.contract` — the pricing model's own "contract generate + compile + test" action — through the one credit ledger, and the debit happens *before* the generator runs, so a caller who cannot afford it gets a 402 and no work started. The price is the preset-agnostic flat rate, not a function of input size: generation is local in-process string assembly, so it costs putty nothing that scales with the contract. **Determinism is part of the contract.** The same `presetId`, `params`, and `features` produce byte-identical `source`, so it can be diffed, committed, and hashed. `fingerprint` is the SHA-256 of it, which is what lets a later deploy tell whether the file is still the one the generator produced; a mismatch means it was hand edited and the contract's label drops to `experimental`. **Version pinning.** `openZeppelinContractsVersion` and `foundryRemappings` come out of the installed Wizard, not out of a constant in putty, so the version in this response, the `Compatible with OpenZeppelin Contracts` line in the source, and the remapping written to `remappings.txt` cannot disagree. **What you must send.** Every value in `params` is a string or a number, never a parsed Solidity value, and an array parameter is JSON array text (`"[\"0xYourWallet\"]"`), which is what a form field and a model both produce naturally. A required parameter that is missing is a 400 naming it — see `error.problems`. **The `features` block only affects the `wizard` presets.** The `ours` presets are putty's own source and their features are fixed; sending the block with an `ours` preset is accepted and ignored rather than refused, so one form can serve every preset.