XChain Platform Action - ISSUE

This action creates or updates a TICK.

Wallet issuer flow. The xchain-wallet ships a Manage Token surface (per-token admin page reachable from My Tokens) that wraps the issuer actions: ISSUE, MINT, DESTROY, DIVIDEND, AIRDROP, BROADCAST, supply/description locks, ownership transfer, dispenser creation, in a guided UI with owner-gate and confirm-prelude steps. The protocol-level fields below are the canonical source; the wallet is one of several clients that can build these transactions.

PARAMS

Formats

Version 0

• VERSION|TICK|MAX_SUPPLY|MAX_MINT|DECIMALS|DESCRIPTION|MINT_SUPPLY|TRANSFER|TRANSFER_SUPPLY|LOCK_MAX_SUPPLY|LOCK_MAX_MINT|LOCK_DESCRIPTION|LOCK_SLEEP|LOCK_CALLBACK|CALLBACK_BLOCK|CALLBACK_TICK|CALLBACK_AMOUNT|ALLOW_LIST|BLOCK_LIST|MINT_ADDRESS_MAX|MINT_START_BLOCK|MINT_STOP_BLOCK|LOCK_MINT|LOCK_MINT_SUPPLY|MEMO

Version 1 - Edit DESCRIPTION

• VERSION|TICK|DESCRIPTION|MEMO

Version 2 - Edit MINT PARAMS

• VERSION|TICK|MAX_MINT|MINT_SUPPLY|TRANSFER_SUPPLY|MINT_ADDRESS_MAX|MINT_START_BLOCK|MINT_STOP_BLOCK|MEMO

Version 3 - Edit LOCK PARAMS

• VERSION|TICK|LOCK_MAX_SUPPLY|LOCK_MAX_MINT|LOCK_DESCRIPTION|LOCK_SLEEP|LOCK_CALLBACK|LOCK_MINT|LOCK_MINT_SUPPLY|MEMO

Version 4 - Edit CALLBACK PARAMS

• VERSION|TICK|CALLBACK_BLOCK|CALLBACK_TICK|CALLBACK_AMOUNT|MEMO

Version 5 - Edit LIST PARAMS

• VERSION|TICK|ALLOW_LIST|BLOCK_LIST|MEMO

Version 6 - Bind/unbind a CONTROLLER for one ACTION_CLASS

• VERSION|TICK|CONTROLLER|ACTION_CLASS|COOLDOWN_BLOCKS|UNBIND|MEMO

Version 7 - Bridge opt-in

• VERSION|TICK|BRIDGE_CHAINS|MIN_DEPTH|LOCK_BRIDGE|MEMO

Examples

ISSUE|0|JDOG
This example issues a JDOG token 

ISSUE|0|JDOG|1||||1|||1
This example issues a JDOG token with MAX_SUPPLY set to 1, Mints 1 token via MINT_SUPPLY, and has LOCK_MAX_SUPPLY set to 1 to permanently lock the MAX_SUPPLY

ISSUE|0|JDOG|0|0|0|http://example.com/images/JDOG_icon.png
This example issues a JDOG token with a DESCRIPTION which points to an icon

ISSUE|0|JDOG|0|0|0|http://example.com/images/JDOG_icon.png|0|1ExampleAddressXXXXXXXXXXXXXXXXXXX
This example issues a JDOG token with a DESCRIPTION which points to an icon, and transfers token ownership to 1ExampleAddressXXXXXXXXXXXXXXXXXXX

ISSUE|0|JDOG|1000|1|0
This example issues a JDOG token with a max supply of 1000, and a maximum mint of 1 JDOG per mint

ISSUE|0|JDOG|1000|1|0|BTNS Tokens Are Cool!
This example issues a JDOG token with a max supply of 1000, and a DESCRIPTION of 'BTNS Tokens are Cool!'

ISSUE|0|BRRR|10000000000000000000|10000000000000|0|https://example.com/json/JDOG.json|100
This example issues a BRRR token with a max supply of 1 Quandrillion supply and a maximum mint of 1 Trillion BRRR per mint, associates a JSON file with the token, and immediately mints 100 BRRR to the broadcasting address.

ISSUE|0|TEST|100|1|0||1|1ExampleAddressXXXXXXXXXXXXXXXXXXX|1ExampleAddressXXXXXXXXXXXXXXXXXXX
This example issues a TEST token with a max supply of 100, and a maximum mint of 1 TEST per mint. This also mints 1 TEST token, and transfers ownership AND initial token supply to 1ExampleAddressXXXXXXXXXXXXXXXXXXX

Rules

• TICK must be 1 to 250 characters in length
• TICK characters allowed are :
  • Alphanumeric characters : a-zA-Z0-9
  • Special characters: ~!@#$%^&*()_±={}[]:<>.?
• TICK characters NOT allowed are :
  • pipe | (used as field separator)
  • semicolon ; (used as command separator)
  • backslash \ (reserved)
  • slash / (used as directory indicator)
  • ^ (caret) cannot be used as first character in a TICK name (used as ticker id indicator)
• Period . is allowed inside a TICK name as the parent/child separator (e.g. JDOG.SUB1), but a TICK may not begin or end with a period
• First ISSUE with valid status will be the owner of the TICK
• Additional ISSUE transactions after first valid ISSUE, will be considered invalid and ignored, unless broadcast from TICK owners address
• DECIMALS can not be changed after TICK supply is issued and/or minted
• MAX_SUPPLY max value is 1,000,000,000,000,000,000,000 (1 Sextillion)
• MAX_SUPPLY can not be set below existing supply
• LOCK_MAX_SUPPLY can only be set to 1 when the token’s MAX_SUPPLY is set (MIN_TOKEN_SUPPLY or greater), declared in the same ISSUE or already on the token record. Minted supply is NOT required: a fair-mint token may declare its MAX_SUPPLY and permanently lock it at issuance, before any supply exists. Setting LOCK_MAX_SUPPLY with no MAX_SUPPLY declared is invalid.
• On any chain other than BTC, a broadcast ISSUE of the XCHAIN (GAS) tick is refused with invalid: TICK (BTC-only), from every source including the GAS address, on every network including regtest; the reserved-tick check is case-folded (btc, BTC, Btc, … are all reserved everywhere), closing a gap where an exact-case check let a mismatched-case ticker through. System-injected creation of the tick (the XBRIDGE v2/v5 settle leg creating a chain’s first shadow row) is exempt from this refusal: it is not a broadcast ISSUE. See Cross-Chain Bridge and Token Bridge.
• Reserving room for chains XChain integrates later. Behind TICK_NAMESPACE_ACTIVATION, two further rules protect the short and chain-code namespace before a squatter can take it: a top-level ISSUE that would CREATE a brand-new tick shorter than four characters is refused with invalid: TICK (length) (editing or re-issuing an existing tick, including the ^id form, is unaffected, so anything issued before the flag keeps its owner and supply); and a fixed list of future chain codes (RESERVED_FUTURE_ROOTS, e.g. ETH, SOL, AVAX, …; see Flag-Day Values for the exact list) is reserved the same way BTC, LTC and DOGE already are, refused with invalid: TICK (reserved). Both rules apply to top-level creation only; a subasset such as ABCD.X is unaffected by the length floor. Below the activation the handler is unchanged.
• Coin-qualified ticker namespace. At or above LIST_TICK_COIN_ACTIVATION, a new top-level TICK whose name begins with a coin root (BTC, LTC or DOGE, case-folded) followed by a colon, or with a RESERVED_FUTURE_ROOTS entry followed by a colon, is refused with invalid: TICK (reserved), unless a token of that name already exists. Existing tickers and the ^id form are unaffected. Below the gate the handler is unchanged.
• Format 7 refusals, in addition to the field checks above: a destination not in COINS other than this chain is invalid: BRIDGE_CHAINS; a format 7 on a row with LOCK_BRIDGE already set is invalid: BRIDGE_CHAINS (locked); a non-empty BRIDGE_CHAINS naming a native tick that contains a dot is invalid: TICK (subassets are not bridgeable yet); a non-empty BRIDGE_CHAINS on a token carrying a live ALLOW_LIST, BLOCK_LIST or controller binding is invalid: TICK (policy-bound tokens are not bridgeable yet); a non-empty BRIDGE_CHAINS whose ALLOW_LIST or BLOCK_LIST membership exceeds XPOLICY_MAX_MEMBERS (10,000) is invalid: TICK (policy list exceeds XPOLICY_MAX_MEMBERS). Behind TOKEN_POLICY_INHERITANCE_ACTIVATION the policy-bound refusal lifts (see Token Bridge); the controller refusal and the membership ceiling never lift on their own.
• Formats 5 and 6 on a bridged token. While a row’s BRIDGE_CHAINS is non-empty or its bridged bit is set (the bit is set by the first applied bridge lock and never cleared), a format 5 (list edit) or format 6 (controller bind/unbind), and a format 0 re-issue carrying a non-empty ALLOW_LIST or BLOCK_LIST, are refused with invalid: TICK (bridged tokens cannot be policy-bound yet). Emptying BRIDGE_CHAINS afterward does not reopen the door while bridged copies are outstanding. Behind TOKEN_POLICY_INHERITANCE_ACTIVATION, formats 5 and a listed format 0 on a bridged token apply and propagate to every bridged copy (see Token Bridge); a controller bind (format 6) on a bridged token stays refused either way.
• Format 6 refusals (controller bind/unbind) are listed in Bind and unbind rejections. A class whose unbind is still inside its COOLDOWN_BLOCKS cooldown refuses both a new bind (invalid: ACTION_CLASS (already bound)) and a second unbind (invalid: ACTION_CLASS (already unbinding)), so replacing a controller means unbind, wait out the cooldown, then bind.

Notes

• ISSUE TICK with MAX_SUPPLY and MINT_SUPPLY set to any non 0 value, to mint supply until MAX_SUPPLY is reached (owner can mint beyond MAX_MINT)
• ISSUE TICK with MAX_SUPPLY and MAX_MINT set to any non 0 value, to enable user minting (fair minting)
• ISSUE TICK with LOCK_MAX_SUPPLY set to 1 to permanently lock MAX_SUPPLY
• ISSUE TICK with LOCK_MAX_MINT set to 1 to permanently lock MAX_MINT
• ISSUE TICK with LOCK_MINT set to 1 to permanently prevent use of the MINT command
• ISSUE TICK with LOCK_SLEEP set to 1 to permanently prevent use of the SLEEP command
• ISSUE TICK with LOCK_CALLBACK set to 1 to permanently prevent use of the CALLBACK command
• DESCRIPTION can contain a URL to a an icon to use for this token (48x48 standard size)
• DESCRIPTION can contain a URL to a JSON file with additional information
• DESCRIPTION can NOT contain any pipe | or semi-colon ; characters, as these are reserved
• CALLBACK_BLOCK, CALLBACK_TICK, and CALLBACK_AMOUNT can be edited via ISSUE action if TICK supply is NOT distributed
• Note on BRC20/SRC20 familiarity: In BRC20 and SRC20, a DEPLOY command defines a new token. In XChain, ISSUE fills that role. XChain also has a separate DEPLOY action, but that action deploys a smart contract to the XChain VM; it is not an alias for ISSUE and does not create a token. Clients migrating from BRC20/SRC20 should use ISSUE where they previously used DEPLOY.
• By default any ADDRESS can interact with a TICK, use ALLOW_LIST and BLOCK_LIST to change this behavior
• CONTROLLER binds the TICK to a deployed contract (its ACTION_INDEX) on the same chain for one ACTION_CLASS (transfer/trade/burn/…). Once bound, the indexer runs that contract’s guard method before guarded native actions of that class settle: enabling enforced royalties, transfer policies, and other programmable rules. The contract must exist and be active when bound; a missing/throwing guard is fail-closed (denies the action). Bindings are append-only (use version 6 to bind or, with UNBIND=1, to drop one); the COOLDOWN_BLOCKS committed at bind time is the friction on a later unbind, so holders can gauge how durable the rules are. Full semantics: Controller-Bound Tokens
• MINT_ADDRESS_MAX can be used to limit the maximum TICK AMOUNT that a single address can MINT
• MINT_START_BLOCK and MINT_STOP_BLOCK can be used to determine period(s) when MINT transactions are allowed
• MINT_START_BLOCK and MINT_STOP_BLOCK must be at or after the block the ISSUE confirms in; at/above the ISSUE_INHERITED_MINT_WINDOW activation (see Flag-Day Values) that check applies only when the ISSUE explicitly sets the field, so an owner can re-issue to update other parameters (for example MAX_MINT) after the mint window has opened without restating or moving the window
• MIN_TOKEN_SUPPLY value is 0.000000000000000001
• Use ^ (caret) as prefix when passing TICK_ID for TICK fields (^1234 = TICK_ID 1234)
• Use ^ (caret) as prefix when passing an ADDRESS_ID for address fields (TRANSFER, TRANSFER_SUPPLY) (^57 = ADDRESS_ID 57); see Index ID References
• ISSUE with DECIMALS 0 and LOCK_MAX_SUPPLY 1 is the standard non-fungible token (NFT) pattern: uniques, editions, and parent/child collections are defined in the NFT Standard

Copyright © 2025–2026 Dankest, LLC

Based on XChain Platform by Dankest, LLC – https://dankest.llc

Licensed under the GNU Affero General Public License v3.0 (AGPL-3.0-or-later) with a commercial license available for proprietary use.

You may use, modify, and distribute this material under the terms of the License. See LICENSE and NOTICE for full terms. See the licensing overview.