Contract Templates
A contract template is the Clarity source behind a product type. What the protocol generates, what gets frozen into it, and how capabilities compose in.
A contract template is the Clarity contract definition behind a product type. When a smart product is deployed, the protocol generates a Clarity contract from the template for that product type, freezes the revenue splits into it, and returns the source for your client to sign and broadcast.
You do not author, upload, or select a template. You pick a product type, and the template follows from it. Creators never write Clarity.
Generating a contract
POST /api/contracts/generate takes a productType plus a domain-specific payload:
- The body carries
productType(haiku,openletter,bracket,ticket,game-lobby, and so on) and is validated against the schema for that type - Your API key is checked against the
sourceAppIdin the body - a key that may not act for that app is rejected with403 - A named
recipe, if present, expands into itscapabilitiesandconstraints - If you pass
smartProductId, the contributions on that product are frozen and become the authoritativecreators[], overriding anything the client sent. This is the path to use: the on-chain payout order must match what the protocol reads back by position - The Clarity source is returned as a
.clarattachment for the user to sign
Your client broadcasts the deploy itself through the Privy or BYOW signing path. There is no /api/contracts/deploy endpoint - the protocol never signs a deploy for you.
What ends up in the contract
- Product metadata hash
- Revenue split recipients and percentages, frozen at generation
- Instance tracking (mint counter, owner map)
- Domain-specific functions (
submit-pickson a PREDICTION bracket, the seat, move and claim functions on a GAME lobby) - Any Clarity contributed by the capabilities and constraints you composed
Capabilities compose in
The template is the base. Opt-in capabilities, constraints and attributes are injected into it at generation, so a product that composes nothing yields a plain mint and one that composes feedback yields a contract that can accept notes. You choose the composition; the protocol emits the Clarity.
Frozen splits are permanent
Freezing assigns every contribution a numeric position, 1..N, that survives forever in the deployed contract. On each mint, the contract pays each position the percentage configured for it, and the protocol matches the on-chain transfers back by position to confirm the split executed correctly.
Once a product is PUBLISHED the contract is immutable, so positions can never change. Adding a contributor after launch means publishing a new smart product.
Template attribution
A deployed product also binds to an attributed template record - a developer identity and a royalty rate, keyed by product type and version. It exists so contract-template authorship is concrete and payable. Today protocol-authored templates carry a royalty of 0; a non-zero rate derives a CONTRACT_TEMPLATE_DEVELOPER contribution on the product. It governs attribution and payout, not which Clarity is emitted.
API endpoints
| Method | Path | Description |
|---|---|---|
POST | /api/contracts/generate | Generate the Clarity source for a product type, ready to sign |
See rtClient.contracts for the SDK surface.
Funding Groups
Funding groups are approved charitable causes that can receive revenue splits from smart product mints.
Capabilities, Constraints & Attributes
The three composition kinds. A capability says what a product does, a constraint says what it may not do, and an attribute says what it is. Products are composed from these, not forked from product types.