Choose a Standard
Choose a shipping BitBadges standard by intent, discover its exact CLI builder and actions, and distinguish payment variants from recurring authorization.
Standards are recognizable arrangements of native token approvals, balances, permissions, and trackers. They provide builders and parsers for common applications without deploying a separate smart contract. A collection's advertised standard name is a discovery hint; validate its actual configuration before acting.
For an agent, begin with the user's intended outcome, then select the builder and inspect the resulting transaction. Use the CLI as the primary entry point. Read Build, Validate, and Track before automating a lifecycle. The Token Standard tab documents the underlying chain primitives.
Intent to Standard
| User wants | Standard and details | Creation entry point |
|---|---|---|
| A finite invoice for one payer, a roster, installments, or a target | PaymentRequestV2 | bb build payment-request-v2 |
| A reusable checkout link | PaymentLinkV1 | Same builder, kind: "payment-link" |
| An existing legacy request | PaymentRequest | bb build payment-request |
| Recurring access with explicit renewal consent | Subscriptions | bb build subscription |
| A token backed by a deposited asset | Smart Token | bb build smart-token |
| A token with a chain coin wrapper | IBC Token Factory | Generic collection/session tools; frontend /mint/ibc-token |
| An existing IBC-backed vault configuration | Vault | bb build vault |
| Prepaid units or API credits | Credit Token | bb build credit-token |
| A priced product catalog | Products | bb build product-catalog |
| A verifier-controlled bounty | Bounty | bb build bounty |
| Goal-based funding and its separate settlement lifecycle | Crowdfund | bb build crowdfund |
| An auction | Auction | bb build auction |
| YES/NO positions with a resolver | Prediction Market | bb build prediction-market |
| NFT listings and bids | NFTMarketplace | bb build listing or bb build bid |
| A fungible collection | Fungible Tokens | Generic collection/session tools; fungible-token skill |
| An NFT collection | NFTs | Generic collection/session tools; nft-collection skill |
| Membership managed as a token list | Address List | bb build address-list |
| Short-lived manager-issued credentials | Custom-2FA | bb build custom-2fa |
| Quest completion tokens | Quests | Frontend quest/claims workflow; bb dev skills quest for guidance |
| A single unique NFT | 1 of 1 | Generic collection/session tools; frontend /mint/one-of-one |
| Issuer-authorized token movement | Issuer-Controlled Tokens | Generic collection/session tools; frontend /mint/issuer-controlled |
| Restrict transfers | Non-Transferable | Approval and permission configuration |
| Pool/DEX participation | Liquidity Pools | Existing pool commands; Smart Token --tradable where applicable |
Not every standard has dedicated list, show, or build verbs. The table identifies actual supported surfaces; use --help on the installed CLI to discover exact options. Tags such as Tradable, Subscription, and Invoice may be validator aliases. Do not rewrite stored tags or assume aliases work in every indexer filter.
Payment Selection
| Requirement | Use |
|---|---|
| Alice pays once | Specific payer invoice |
| Anyone pays once | Public invoice |
| Any one of Alice, Bob, or Carol pays | One roster obligation, one payment |
| Alice, Bob, and Carol must each pay | Separate obligation for each payer |
| Any three eligible wallet addresses must pay | One obligation, three required payments, distinct payers |
| Alice pays on several dates | Independent installment obligations |
| Alice pays in smaller increments | Partial-payment quantum and finite target |
| A group contributes toward a direct-payment total | Shared target, with final recipient payouts on each contribution |
| The same checkout can be used repeatedly | Payment link |
| Charge the same user periodically after consent | Subscriptions |
| Hold money for a refund or conditional release | A separately verified escrow/funding standard; direct invoice targets do not escrow |
The nine payment presets describe common shapes. Valid combinations can be classified custom; they still use the same strict terms and on-chain approvals. Payer rules, unit rules, and tracking define the differences.
Agent Discovery
bb --help-json
bb build payment-request-v2 --help
bb pay-requests pay --help
bb dev tools list --names
bb dev skills payment-obligations
bb dev skills subscriptionThe installed CLI's machine-readable command tree describes syntax. Tool schemas describe input shape; the builder's runtime validation also checks cross-field rules. Read the standard's lifecycle before selecting an action. An emitted message is a proposal, and a submitted hash is not confirmed settlement.
Existing Smart Token vault functionality is documented here. The separately proposed Agent Vault work is not required for the main-wallet invoice flow and is not included in these standards' guarantees.
Frontend Coverage
This reference includes every creation family registered in the frontend: invoices (Invoices, legacy PaymentRequest, PaymentRequestV2, PaymentLinkV1), subscriptions, smart tokens, IBC token factory, vaults, credits, products, quests, address lists, Custom-2FA, bounties, crowdfunding, auctions, prediction markets, fungible tokens, NFTs, 1-of-1 NFTs, and issuer-controlled tokens.
Composable capabilities are documented alongside their owning family: NFTMarketplace and Liquidity Pools, Non-Transferable and UI conventions. Leaderboard, Milestones, and ListView:<name> are display tags. They do not introduce new chain primitives. The invoice form's nine presets map to payer rules and payment units, with reusable checkout in Payments.
The CLI JSON recipes document supported builder inputs. Where the frontend offers a template without a dedicated SDK/CLI builder, the page identifies the generic primitives and labels partial JSON as a fragment. Do not treat a display tag, illustrative fragment, or generic tool as a complete standard implementation.
Machine Input
For invoice discovery, the CLI emits the builder parameters under data. These are distinct from the collection's standards tags. For example, this selection fragment requests a finite invoice model, not a complete collection:
{
"version": 2,
"kind": "invoice"
}Add validated obligations and metadata from the complete JSON input. For other families, use the matching bb build recipe and domain action commands on that page. Agents should retain the original input alongside the generated transaction so reviewers can compare intended terms against actual approval criteria.