Four people arrive here. Four different jobs.
Start with the job you need done, not a token ticker. These are illustrative uses of contract building blocks, not ready-made business applications. Your operator defines the rules; mintrr helps make the chain-facing choices and their evidence explicit.
Someone with an idea and a launch date
A token your community holds, with the right limits built in from the start rather than bolted on later. Usually a supply cap, a way to freeze a wallet that is cheating, and a way to stop everything for an hour while you work out what happened.
Start with an explicit plan and a compatible first-party template. Review supply, requested controls and the named owner before generation. Source-marker checks can refuse a missing requested group; compilation and behavior tests answer separate questions. Review the available signing and deployment path rather than treating the plan as a launch.
Nobody can stop you launching a token people lose money on, and nobody here will pretend otherwise. What mintrr does is make sure the controls you chose are the controls you have. If you skip the freeze because it is inconvenient on day one, that is your decision, and you will have it every day after.
Write a useful launch brief, then review how the stages fit together and what exists today. Bring the intended supply policy, transfer rules, owner and recovery responsibilities.
Someone who owns something and wants it on chain
A token that behaves like the asset it represents: limited who can hold it, checked on every transfer, and unable to move to a wallet that should not be holding it.
The existing RWA bundle preview can compile and order a token, identity registry and compliance module, and report configured or unset rules. It prepares a proposed arrangement without signing or broadcasting. That preview is not a completed issuance or a public-chain proof of your asset workflow; deployment wiring and resulting roles need their own evidence.
Name the issuer, eligibility decision-maker and the people responsible for changing or pausing the asset's controls. Ask which requested rules are implemented, which are unset and which need an extension. Technical restrictions do not settle legal eligibility, title or the operator's obligations; qualified legal and operational review remains separate.
A token does not create buyers, reserves, redemption or liquidity. Describe those arrangements separately from the contract. Transfer permissions may themselves be restricted, so do not assume that representing an asset on a ledger makes it freely tradable.
A business that needs this to work on a Tuesday
Customers to pay, get something of value back, and be able to leave. You want to be able to refund one, block one fraudster, and change a price without a sprint.
Choose compatible contract building blocks for the asset layer, then inspect their available controls and limits. Expiry, access conditions, supply limits or transfer restrictions are distinct choices, not a complete subscription service. Your application still owns customer accounts, service delivery, refunds, support and the meaning of a balance.
What is this, for tax and accounting purposes, and does it create an obligation you did not want? That is a real question with real money behind it and no technical answer. Everything else on this page is downstream of it.
Keep the customer experience in your application and use the available engine operations for chain-facing work. Describe the operation, caller and approval requirements before integrating. A headless interface does not itself supply your login system, customer support process or a hosted service package.
A developer wiring this into something you are building
To call one thing and get a verified contract, a role matrix, a gas estimate and an unsigned transaction. And to have it fail loudly rather than return something plausible.
The CLI, HTTP API and MCP expose engine operations. Discover the available command, route or tool, check its required scope and handle its refusals. Your application still needs its own identity and approval design; connecting an interface does not establish that design or authorize a transaction.
Requested source-marker groups are checked during generation; a missing group is refused. Marker presence is not complete behavioral or ABI verification, and a successful build is not a live deployment. Use the public capability map and the evidence for the selected operation. The engine source and internal findings register are private, not visitor-facing proof links.
For operators who already have an installed CLI, start with discovery, not a deployment command:
mintrr --help mintrr draft --help mintrr manage --help
Read what a preview actually tells you, then use the connection guide for the documented agent-access path. Access and installation depend on your environment; this page does not offer a public source checkout.
Ask what a chain can do and what it refuses before designing anything. The refusal layer is the product: a harness that gets told "no" correctly is worth more than one that gets told "yes" easily.
The four things that do not change
Preparation is not signing
Draft preview and workbench Export do not sign or broadcast. Any execution path needs its own documented controls and approval. Never put private keys or recovery words in a plan.
Checks have a stated scope
A missing requested source-marker group is refused. A present marker or a successful build is not complete behavioral verification. Read what was checked, not just the success label.
Match the claim to observed state
A result on one network or configuration is not evidence for another. Check the network, transaction result and relevant state or role read-back. The current capability list is not a receipt for your particular operation.
Read the limits with the result
Source checks, compiler output, runtime tests and observed chain state are different evidence. None is a blanket security assessment or a legal conclusion about your business.