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#

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 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#

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, permissions, and all applicable approval levels together.

Discover exact tools and primitives#

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, Custom-2FA, fungible tokens, NFT collections, immutability, burning, minting, auto-mint, multisignature voting, and token ownership criteria.

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.

{
  "manager": "bb1zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zql3w7",
  "creator": "bb1zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zql3w7",
  "uri": "https://example.com/metadata.json"
}

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

Review the resulting proposal using the CLI 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.

{
  "creator": "bb1zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zql3w7",
  "burnable": false,
  "transferable": false,
  "uri": "https://example.com/metadata.json"
}

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

Review the resulting proposal using the CLI 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.

{
  "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.

{
  "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.

{
  "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:

A standards-field fragment, not a deployable collection:

{
  "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:

{
  "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 or NFT 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.