Shape a use case
A loyalty asset, access pass, subscription, escrow or tokenized product. Explain the users, the rules and the part that should live on a chain.
Tell us what you're building.
A first asset, an integration, a difficult constraint or a bug. Start with the context and the question you need answered.
You do not need a finished contract or a final technical plan. Describe who the product is for, what it should do and where you need help.
When a conversation helps.
Reach out when the business goal is clear but the shape, integration or next step still needs work.
Plan an integration
Bring a CLI workflow, an agent harness or an application you want to connect. Describe what is already in place and the interface you need.
Report a problem
A refusal you cannot explain, a missing capability, a broken command or unclear documentation. Share a small example and a redacted error message.
A useful first message.
A few concrete details make the question easier to understand.
- The goal. What are you building, and who will use it?
- The context. Your preferred chain or network, existing system and current stage. It is fine if these are undecided.
- The question. What do you need to decide, connect or fix?
- The constraints. A deadline, required behaviour or a limit that matters. Share only information you are comfortable sending by email.
Copy a starting point
Subject: mintrr use case
What I'm building:
Who it is for:
Current stage:
Preferred chain or network:
Where I need help:
Important constraints:For a bug, include the mintrr version, operating system, terminal if relevant, steps to reproduce, and expected versus actual behaviour. Redact secrets before sharing logs.
Before you write.
Answers to common starting questions.
Do I need a finished contract or a technical specification?
No. Start with the business goal, the people involved and what should happen. Include a draft or public contract reference if you already have one, but it is not a prerequisite for a conversation.
What if I have not chosen a chain?
Describe the constraints that matter: users, network costs, existing integrations and required asset behaviour. If you have a preference, name it and distinguish testnet from mainnet. Chain maturity is shown separately on How it works.
Can I ask about alpha access or pricing?
Yes. Explain what you want to try and the scope you have in mind. Compute is free during the alpha within a bounded allowance; network fees are separate. The pricing page explains the current terms and the prices that are not set yet.
Do I need an AI agent to use mintrr?
No. The ordinary CLI and optional terminal workbench do not require an AI agent. The workbench can inspect local records and prepare a local draft without making AI requests. See the CLI overview for the current boundary.
Can I ask about an existing contract or application?
Yes. Explain the workflow or integration question and, if appropriate, include the public contract address and its network. A public address is context, not proof that you control the asset. Never email the key that controls it.
What makes a bug report useful?
Include the version, the command or screen involved, a small set of repeatable steps, what you expected and what happened instead. For terminal issues, include the terminal application and window size. Send a redacted excerpt, not a raw environment dump.
Is a conversation or a verification result a security audit?
No. Automated source checks and compilation do not prove how a contract will behave in every situation or replace an independent security audit. Say if you need an external security review or legal advice; those needs are separate from using the toolkit.
Will you need my private key, recovery phrase or token?
Do not send them. Your message should describe the problem, not transfer access to an account or permission to sign. Deployment and privileged actions have their own review and human-confirmation requirements.