# Access, membership, and token capabilities

These standards configure balances and authorization. A standard label is a discovery hint until the actual approval, invariant, and permission structure passes the corresponding validator.

## Address List

`bb build address-list --creator <address> --manager <address> --uri <metadata-uri>` creates an `Address List` token collection. Membership uses token ID 1. The manager-add approval mints membership, and manager-remove burns it with the configured manager's authorization. The builder defaults the approval initiator to the creator when no manager is supplied.

This collection standard is distinct from the chain's standalone address-list resource. The CLI has no dedicated Address List membership action group. Use the session tools with `address-list.manager-add` and `address-list.manager-remove` presets, then build and validate the matching transfer. Do not invent `bb address-lists add` as a collection-standard action.

Check current membership balances and ownership times, not historical issuance alone. Removal is an authorized transfer, not deletion of the original transaction. User incoming approval requirements and collection permissions still matter. A manager field change should not be assumed to rewrite an address embedded in an existing approval.

## Custom-2FA

```bash
bb build custom-2fa --creator "$CREATOR" --uri "$METADATA_URI"
bb custom-2fa mint "$COLLECTION_ID" --creator "$MANAGER" --to "$HOLDER" --expiration 5m
```

The `Custom-2FA` builder supports optional `--burnable` and `--transferable`. Its manager-only mint action sets a short ownership lifetime (default five minutes, configurable with `--expiration`); protected collections must separately require that token through ownership criteria. Creating a 2FA collection does not automatically protect another collection, wallet, or bank transfer.

Ownership gates must specify the correct collection, token IDs, amount range, and time semantics. Transferable or burnable factors have different lifecycle implications: a factor may move to another holder or cease to satisfy a gate. The existing vault's `--require-2fa` uses current ownership of token ID 1. Inspect the actual gate before describing any token as a universal second factor.

## Quests

Start with `bb dev skills quest` and the frontend quest/claims flow. The shipping CLI has no `bb build quest`, `bb build quests`, or `bb quests` action family. The former CLI constructor was removed because its empty-root challenge was rejected by the chain. The frontend claims workflow needs configured completion criteria; there is no equivalent one-command CLI deployment recipe.

The retained SDK `buildQuests` function is a secondary template/recognizer reference. Building its JSON successfully does not prove that its default challenge is claimable on chain. Read the [quest skill](https://docs.bitbadges.io/agents/skills/quest) before modifying the template.

The template creates the `quests-approval` reward path, an overall claim cap, and a challenge tracker, plus a burn approval. Rewards use the approver-funded coin transfer path. The simple builder's empty-root challenge is not a valid deployable completion proof and is rejected by the chain. Configure and verify the intended proof/claim criteria before promising task-gated rewards. Track claim counters, challenge usage, and available reward funds separately; a maximum claim count does not fund the reward budget.

## Fungible Tokens, NFTs, and Non-Transferable

| Standard/capability | Configuration path | State to inspect |
| --- | --- | --- |
| `Fungible Tokens` | Generic collection/session tools guided by the fungible-token skill | Token supply, balances, mint permissions, transfer approvals |
| `NFTs` | Generic tools guided by the nft-collection skill | Per-ID supply and ownership, metadata, mint and transfer constraints |
| `Non-Transferable` | Configure approval and permission restrictions | All possible post-mint transfer paths, including manager overrides |
| `NFTMarketplace` | Add tradable collection capability and user orders | See [markets](https://docs.bitbadges.io/standards/markets) for listing/bid lifecycle |

There is no standalone `bb build fungible-token`, `bb build nft`, or non-transferable action group. `bb build send` and `bb build transfer` are generic movement builders; they cannot override a collection's rules. Burning, minting, auto-mint, immutability, multisignature voting, and token-gated payment protocols are composable capabilities documented in skills, not automatically separate collection standards or new CLI action families.

A unique token ID alone does not prove a one-unit lifetime supply cap. A missing public transfer approval alone does not prove that no manager can move tokens. Inspect [invariants](https://docs.bitbadges.io/token-standard/approval-criteria/invariants), [permissions](https://docs.bitbadges.io/token-standard/concepts/permissions), and all applicable approval levels together.

## Discover exact tools and primitives

```bash
bb dev tools list
bb dev tools call list_presets --args '{"skill":"address-list"}'
bb dev skills custom-2fa
bb dev resources list
```

Tool descriptors include machine-readable input schemas. Presets are approval-level components, not complete collection templates. Validate the assembled collection and resulting transaction; a schema-valid component alone does not establish a valid standard or authorize a transfer.

Read the deeper guides for [address lists](https://docs.bitbadges.io/agents/skills/address-list), [Custom-2FA](https://docs.bitbadges.io/agents/skills/custom-2fa), [fungible tokens](https://docs.bitbadges.io/agents/skills/fungible-token), [NFT collections](https://docs.bitbadges.io/agents/skills/nft-collection), [immutability](https://docs.bitbadges.io/agents/skills/immutability), [burning](https://docs.bitbadges.io/agents/skills/burnable), [minting](https://docs.bitbadges.io/agents/skills/minting), [auto-mint](https://docs.bitbadges.io/agents/skills/auto-mint), [multisignature voting](https://docs.bitbadges.io/agents/skills/multi-sig-voting), and [token ownership criteria](https://docs.bitbadges.io/token-standard/approval-criteria/token-ownership).

## Membership JSON

Save the following input as `address-list.json`, replace the demo addresses and metadata, then build it with the CLI command below. `manager` scopes the mint/remove initiator inside the approvals. `creator` is its fallback, not a request to mint membership immediately. The command returns a collection proposal; use the separate membership transfer and verify balances after confirmation.

<!-- sdk-example: buildAddressList -->
```json
{
  "manager": "bb1zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zql3w7",
  "creator": "bb1zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zql3w7",
  "uri": "https://example.com/metadata.json"
}
```

```bash
bb build address-list --json address-list.json \
  --creator "$CREATOR" --output-file address-list-proposal.json
```

Review the resulting proposal using the [CLI lifecycle](https://docs.bitbadges.io/standards/lifecycle). SDK reference: `buildAddressList`.

## 2FA JSON

Save the following input as `custom-2fa.json`, replace the demo addresses and metadata, then build it with the CLI command below. `creator` is required to restrict issuance to the manager. The mint action chooses ownership times; the template does not make another collection require this factor. Configure the protected approval's ownership gate separately.

<!-- sdk-example: buildCustom2FA -->
```json
{
  "creator": "bb1zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zql3w7",
  "burnable": false,
  "transferable": false,
  "uri": "https://example.com/metadata.json"
}
```

```bash
bb build custom-2fa --json custom-2fa.json \
  --creator "$CREATOR" --output-file custom-2fa-proposal.json
```

Review the resulting proposal using the [CLI lifecycle](https://docs.bitbadges.io/standards/lifecycle). SDK reference: `buildCustom2FA`.

## Quest Template

There is no dedicated quest CLI constructor. Begin with `bb dev skills quest` and the frontend quest form; configure real completion criteria before constructing a claim path. The following is a **secondary SDK template reference**, not a complete runnable CLI recipe or a deployable default. The retained builder emits an empty-root challenge; proper claims configuration is required. `reward` is a display-unit amount per successful claim; `maxClaims` limits the approval counter. This default template is not evidence of completing an external task. Set real challenge criteria and fund the reward source before permitting claims.

<!-- sdk-example: buildQuests -->
```json
{
  "reward": 1,
  "denom": "BADGE",
  "maxClaims": 100,
  "uri": "https://example.com/metadata.json"
}
```

## 1 of 1

The frontend's `1 of 1` creation template is a constrained NFT configuration. It creates only token ID 1, sets `maxSupplyPerId` to 1, prohibits custom ownership times and forceful post-mint transfers, and caps the mint approval at one successful transfer with auto-deletion after its cap. Its UI name is not a substitute for checking these rules on an existing collection.

This **configuration fragment** shows the ID and invariant fields to inspect; it is not a complete message or builder input. Do not add the label to an unconstrained NFT and claim uniqueness.

```json
{
  "standards": ["1 of 1"],
  "validTokenIds": [{ "start": "1", "end": "1" }],
  "invariants": {
    "maxSupplyPerId": "1",
    "noCustomOwnershipTimes": true,
    "noForcefulPostMintTransfers": true
  }
}
```

Creation is available at `/mint/one-of-one` in the frontend. For automation use collection/session primitives and inspect the complete mint approval and immutable restrictions. There is no dedicated `bb build one-of-one` command. Query both current ownership and supply; a transfer changes the owner without creating another unique item.

## Issuer-Controlled Tokens

The frontend's `Issuer-Controlled Tokens` template scopes transfer initiation to the manager and explicitly overrides sender outgoing and recipient incoming approvals. That is the intended issuer authority, and holders must understand it. The manager address embedded in an approval and the collection's current `manager` field are distinct configuration facts.

This **approval fragment** illustrates the authority to inspect, with a demo manager address. Other approval fields, balances, ranges, permissions, and the surrounding message are omitted.

```json
{
  "initiatedByListId": "bb1xvenxvenxvenxvenxvenxvenxvenxvenlrd2nm",
  "approvalCriteria": {
    "overridesFromOutgoingApprovals": true,
    "overridesToIncomingApprovals": true
  }
}
```

The frontend supports a permanent-lock choice that removes the transfer approvals and manager. Review the emitted permissions and invariants before making an irreversibility claim. Use `/mint/issuer-controlled` or the generic collection/session tools; no dedicated issuer-controlled CLI builder exists. Track balances and approval changes, not an invoice-style payment counter.

## Display Conventions

These frontend tags select views. They do not create authorization, prove completion, or enforce a financial standard:

| Tag | Frontend behavior | Enforcement to configure separately |
| --- | --- | --- |
| `Leaderboard` | Points leaderboard on token pages | Supply, transfer rules, scoring and distribution policy |
| `Milestones` | Milestone view on collection and token pages | Ownership or claim criteria for any actual entitlement |
| `ListView:<name>` | Named list-style view using the milestone component | Underlying token/approval rules; suffix is only a tab name |

A **standards-field fragment**, not a deployable collection:

```json
{
  "standards": ["NFTs", "Milestones", "ListView:Deliverables"]
}
```

The frontend chooses a matching enabled display convention in stored array order for the relevant page. Retain that order when editing tags. `Tradable NFTs` is a frontend selection combining `NFTMarketplace` and `NFTs`; use those actual tags and validate the marketplace transfer configuration. `Non-Transferable` is likewise a capability that must agree with the real transfer paths.

## Generic Token JSON

`Fungible Tokens`, `NFTs`, and `Non-Transferable` use collection/session tools rather than dedicated CLI constructors. A standard-selection tool argument is valid JSON but does not create minting, supply limits, or transfer authorization:

```json
{
  "standards": ["Fungible Tokens", "Non-Transferable"]
}
```

Inspect `bb dev tools list` for `set_standards`, `set_valid_token_ids`, `set_invariants`, `set_permissions`, and approval tools. Use the [fungible-token](https://docs.bitbadges.io/agents/skills/fungible-token) or [NFT](https://docs.bitbadges.io/agents/skills/nft-collection) recipe to assemble the remaining fields in the same session, then retrieve and validate the whole transaction. For NFTs, use the `NFTs` tag and explicitly bound per-ID supply. Never submit the selection fragment alone as `MsgUniversalUpdateCollection`.

Compatibility views can also recognize the legacy `No User Ownership` label. It is not a separate shipping constructor; inspect the actual ownership/balance rules and collection behavior before interpreting it.