Playbooks Overview
Playbooks are end to end blueprints for building real products on AMP2. Where the Issuer Guide explains each SDK action in isolation, a playbook shows how to assemble those actions
Playbooks are end to end blueprints for building real products on AMP2. Where the Issuer Guide explains each SDK action in isolation, a playbook shows how to assemble those actions into a working product: who the parties are, which AMP2 configuration choices apply, how the wallets fit together, what the lifecycle operations look like, and how the product is run day to day.
Why playbooks exist
AMP2 is a small set of powerful primitives: asset issuance, restrictions, lock and unlock, reissue and burn, Registry v2 metadata, and HSM enforced cosigning. The same primitives can be combined in many ways, and the right combination depends entirely on what you are trying to build.
Reading the SDK reference tells you what each call does. A playbook tells you which combination of calls makes sense for a specific use case, in what order, and with which configuration values. It is the bridge between the platform documentation and a production deployment.
What every playbook covers
Every playbook is structured around the same questions, so two playbooks can be compared side by side.
| Section | Question it answers |
|---|---|
| Overview | What is the product, who are the parties, what is the high level lifecycle? |
| Project design | What needs to be decided off chain (regulation, custody, partners) before touching AMP2? |
| Asset configuration | Which exact issuance parameters and Registry v2 fields fit this product? |
| Wallet topology | Which wallets do you register, and how do they relate to one another? |
| Lifecycle operations | What are the day to day flows (mint, redeem, distribute, lock, burn)? |
| Compliance and reporting | How are restrictions, locks, and audit trails used to satisfy regulators? |
| Runbook | What runs every day, every month, and during incidents? |
How to use a playbook
- Skim the playbook's overview to confirm it matches your use case.
- Walk through the project design page and capture the open decisions in your own planning document.
- Use the asset configuration and wallet topology pages as your build template on testnet.
- Treat the lifecycle, compliance, and runbook pages as the source for your operational procedures.
- Cross reference the linked Issuer Guide and Concepts pages whenever you need the underlying SDK detail.
A growing collection
Playbooks are added as new product patterns emerge on AMP2. Each one targets a specific, real customer profile, so the configuration choices and operational guidance can be concrete rather than generic. Browse the available playbooks in the sidebar; if your product does not match any of them yet, the closest one is usually a good starting point because the AMP2 primitives compose freely across patterns.
What playbooks are not
| Not legal advice | Choosing a regulatory wrapper, drafting a prospectus, and meeting jurisdictional rules are the issuer's responsibility. |
| Not a replacement for the SDK reference | Code samples are intentionally minimal; the Issuer Guide is the source of truth for SDK calls. |
| Not vendor recommendations | When a playbook names a partner or venue, it is describing the existing ecosystem rather than endorsing a provider. |