# Auto-Mint

> Mint and distribute tokens to recipients at collection creation time using MsgTransferTokens

**Category:** Features

## Summary

Post-creation minting — adds MsgTransferTokens messages to the transaction so tokens are distributed immediately after collection creation.

* Transaction can contain MsgUniversalUpdateCollection PLUS one or more MsgTransferTokens messages
* All transfer messages use collectionId: "0" to reference the just-created collection
* prioritizedApprovals MUST always be specified (use \[] if none needed)
* from: "Mint" for minting new tokens, bb1... address for peer-to-peer transfers
* The signing user (creator) is the initiator — collection must have an approval allowing this
* All numbers as strings — "1" not 1
* Prefer predeterminedBalances with x0 increments over maxNumTransfers for better frontend UX

When to use:

* User asks to mint tokens to themselves or others at creation time
* Initial distribution or pre-allocation of tokens
* Manager-only collections where the manager should receive all tokens immediately

When NOT to use:

* Public mint collections (users mint later via approval)
* Subscription collections (users mint on subscribe)
* Smart tokens (users deposit IBC coins to mint)
* Any collection where minting happens post-creation through approvals

## Instructions

## Auto-Mint — Post-Creation Transfers

A transaction can contain the collection creation message (MsgUniversalUpdateCollection) PLUS one or more MsgTransferTokens messages. All use collectionId: "0" to reference the just-created collection.

### MsgTransferTokens Structure

```json
{
  "typeUrl": "/tokenization.MsgTransferTokens",
  "value": {
    "creator": "bb1...",
    "collectionId": "0",
    "transfers": [{
      "from": "Mint",
      "toAddresses": ["bb1recipientaddress..."],
      "balances": [{
        "amount": "1",
        "tokenIds": [{ "start": "1", "end": "1" }],
        "ownershipTimes": [{ "start": "1", "end": "18446744073709551615" }]
      }],
      "prioritizedApprovals": [{
        "approvalId": "the-mint-approval-id",
        "approvalLevel": "collection",
        "approverAddress": "",
        "version": "0"
      }],
      "onlyCheckPrioritizedCollectionApprovals": false,
      "onlyCheckPrioritizedIncomingApprovals": false,
      "onlyCheckPrioritizedOutgoingApprovals": false,
      "memo": ""
    }]
  }
}
```

### When to add a transfer message

* User asks to mint tokens to themselves or others at creation time
* User wants initial distribution or pre-allocation of tokens
* Manager-only collections where the manager should receive all tokens immediately
* Any scenario where tokens should exist in wallets right after collection creation

### When NOT to add a transfer message

* Public mint collections (users mint later via the approval)
* Subscription collections (users mint on subscribe)
* Smart tokens (users deposit IBC coins to mint)
* Any collection where minting happens post-creation through approvals

### Critical transfer rules

1. **prioritizedApprovals MUST be specified** — even if empty \[]. Match the approvalId to one of the collection's collectionApprovals.
2. **from: "Mint"** for minting new tokens. Use a bb1... address for peer-to-peer transfers.
3. **The signing user (creator) is the initiator** — the collection must have an approval that allows this address as initiatedBy.
4. **collectionId: "0"** is auto-set — it references the collection created by message\[0] in the same transaction.
5. **All numbers as strings** — "1" not 1.
6. **Prefer predeterminedBalances for one-time or fixed-use approvals** — Use incrementedBalances with x0 increments (incrementTokenIdsBy: "0", incrementOwnershipTimesBy: "0") instead of relying solely on maxNumTransfers. The frontend auto-detects predeterminedBalances and shows users the exact tokens they will receive, providing much better UX. Avoid manualBalances; incrementedBalances with x0 increments is preferred.

### Time-Dependent Ownership

For expiring tokens, calculate timestamps:

* Current time: use get\_current\_timestamp tool (milliseconds since epoch)
* Example: 5 minutes from now = current timestamp + (5 \* 60 \* 1000)

```json
"ownershipTimes": [{
  "start": "1706000000000",
  "end": "1706000300000"
}]
```

### Session-based patch operations

* add\_transfer: { op: "add\_transfer", transfer: { transfers: \[...] } } — appends a MsgTransferTokens to the transaction
* remove\_transfer: { op: "remove\_transfer", index: 0 } — removes transfer message by index (0-based among transfer messages)
* update\_transfer: { op: "update\_transfer", index: 0, changes: {...} } — deep-merges changes into the transfer message

### Common mistakes

* DON'T forget to add prioritizedApprovals in MsgTransferTokens — even if empty (\[]), this field must be present or the transfer fails.
* DON'T forget that the collection must have a mint approval that allows the creator as initiatedBy.
* DON'T add transfer messages for subscription, smart token, or public mint collections — minting happens post-creation through approvals.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.bitbadges.io/token-standard/skills/auto-mint.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.