# Choose a Standard

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](https://docs.bitbadges.io/cli) as the primary entry point. Read [Build, Validate, and Track](https://docs.bitbadges.io/standards/lifecycle) before automating a lifecycle. The [Token Standard](https://docs.bitbadges.io/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](https://docs.bitbadges.io/standards/payments) | `bb build payment-request-v2` |
| A reusable checkout link | [PaymentLinkV1](https://docs.bitbadges.io/standards/payments#reusable-links) | Same builder, `kind: "payment-link"` |
| An existing legacy request | [PaymentRequest](https://docs.bitbadges.io/standards/payments#legacy-requests) | `bb build payment-request` |
| Recurring access with explicit renewal consent | [Subscriptions](https://docs.bitbadges.io/standards/subscriptions) | `bb build subscription` |
| A token backed by a deposited asset | [Smart Token](https://docs.bitbadges.io/standards/smart-tokens) | `bb build smart-token` |
| A token with a chain coin wrapper | [IBC Token Factory](https://docs.bitbadges.io/standards/smart-tokens#ibc-token-factory) | Generic collection/session tools; frontend `/mint/ibc-token` |
| An existing IBC-backed vault configuration | [Vault](https://docs.bitbadges.io/standards/smart-tokens) | `bb build vault` |
| Prepaid units or API credits | [Credit Token](https://docs.bitbadges.io/standards/commerce) | `bb build credit-token` |
| A priced product catalog | [Products](https://docs.bitbadges.io/standards/commerce) | `bb build product-catalog` |
| A verifier-controlled bounty | [Bounty](https://docs.bitbadges.io/standards/funding) | `bb build bounty` |
| Goal-based funding and its separate settlement lifecycle | [Crowdfund](https://docs.bitbadges.io/standards/funding) | `bb build crowdfund` |
| An auction | [Auction](https://docs.bitbadges.io/standards/markets) | `bb build auction` |
| YES/NO positions with a resolver | [Prediction Market](https://docs.bitbadges.io/standards/markets) | `bb build prediction-market` |
| NFT listings and bids | [NFTMarketplace](https://docs.bitbadges.io/standards/markets) | `bb build listing` or `bb build bid` |
| A fungible collection | [Fungible Tokens](https://docs.bitbadges.io/standards/access) | Generic collection/session tools; `fungible-token` skill |
| An NFT collection | [NFTs](https://docs.bitbadges.io/standards/access) | Generic collection/session tools; `nft-collection` skill |
| Membership managed as a token list | [Address List](https://docs.bitbadges.io/standards/access) | `bb build address-list` |
| Short-lived manager-issued credentials | [Custom-2FA](https://docs.bitbadges.io/standards/access) | `bb build custom-2fa` |
| Quest completion tokens | [Quests](https://docs.bitbadges.io/standards/access) | Frontend quest/claims workflow; `bb dev skills quest` for guidance |
| A single unique NFT | [1 of 1](https://docs.bitbadges.io/standards/access#1-of-1) | Generic collection/session tools; frontend `/mint/one-of-one` |
| Issuer-authorized token movement | [Issuer-Controlled Tokens](https://docs.bitbadges.io/standards/access#issuer-controlled-tokens) | Generic collection/session tools; frontend `/mint/issuer-controlled` |
| Restrict transfers | [Non-Transferable](https://docs.bitbadges.io/standards/access) | Approval and permission configuration |
| Pool/DEX participation | [Liquidity Pools](https://docs.bitbadges.io/cli/swap) | 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](https://docs.bitbadges.io/standards/payment-payers), [unit rules](https://docs.bitbadges.io/standards/payment-units), and [tracking](https://docs.bitbadges.io/standards/payment-tracking) define the differences.

## Agent Discovery

```bash
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 subscription
```

The 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](https://docs.bitbadges.io/standards/markets), [Non-Transferable and UI conventions](https://docs.bitbadges.io/standards/access#display-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](https://docs.bitbadges.io/standards/payment-payers) and [payment units](https://docs.bitbadges.io/standards/payment-units), with reusable checkout in [Payments](https://docs.bitbadges.io/standards/payments#reusable-links).

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:

```json
{
  "version": 2,
  "kind": "invoice"
}
```

Add validated `obligations` and metadata from the [complete JSON input](https://docs.bitbadges.io/standards/payments#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.