Protocol

Protocol-Level Operations

Understanding protocol-level operations is key for interacting with the blockchain. This section explains how deploy, mint, and transfer messages function, including where they are sent.
GENESIS BLOCK: 11097263
General Rule:
All operations, whether they are part of the tx.data or as emitted contract events, are processed based on the order of the blocknumber and tx_index within the block in a deterministic manner. Future operations will not ever change the outcome of the past events.

Sending Messages

  • Messages are sent as transaction data to the blockchain.
  • Any data that conforms with the open dataURL format are recognized as an inscription. For example: 'data:,{"p":"nip-20", "op":"deploy", "tick":"<TICKER>" '
  • However, the validity of the message are determined according to the following rules

Deploy Operation

  • Message: {"p":"nip-20", "op":"deploy", "tick":"<TICKER>", "max":<MAXAMOUNT>, "lim":<MINT_LIMIT>, "contract":<optional:ADDRESS>, "cmint":<optional:bool>}
  • Recipient: Can be sent to any address.
  • Validation:
    • Checks for the uniqueness of the TICKER. No duplicate is allowed.
    • The ticker has a maximum 10 character limit. and should only contain english characters and numbers. no special character allowed.
    • When contract address is provided, static nip20_allowMint() method of this contract address will be called when validating a mint operation.
    • When the contract address is provided, only this contract can mint the inscriptions through smart contract events. Regular mints may still be allowed depending on other configurations.
    • MINT_LIMIT must be greater than 0.
    • MAX_AMOUNT must be greater than MINT_LIMIT
    • Reserved ticker such as "METIS" or "NUVO" can only be deployed by the Nuvo Team to ensure smooth operation.
    • if cmint is set to true, mints can be done via the contract only. Regular mints in messages are disallowed.

Mint Operation

  • Message: {"p":"nip-20", "op":"mint", "tick":"<TICKER>", "id":"<ID>", "amt":"<AMOUNT>"}
  • Recipient: The address receiving the newly minted token.
  • Validation:
    • Ensures TICKER exists and already deployed and ID is unique.
    • ID does not need to be sequential but must be globally unique.
    • The amount must obey the MAX_AMOUNT and MINT_LIMIT of the deployed token.

Transfer Operation

  • Message: {"p":"nip-20", "op":"tsf", "tick":"<TICKER>", "id":"<ID>"}
  • Recipient: The new owner of the token.
  • Validation:
    • Confirms TICKER and ID, the tx.hash where the inscription happened,exists
    • Sender must be the owner of this inscription.
    • The inscription is currently not listed for sale.

The following operations will be enabled in the future update:

Split Operation - split one inscribed token into two smaller amounts

  • Message: {"p":"nip-20", "op":"split", "tick":<TICKER>, "id":<ID>, "amt1":<AMOUNT1>, "amt2":<AMOUNT2> }
  • Recipient: The owner of the two splited inscriptions.
  • Validation: Confirms TICKER and ID, the tx.hash where the inscription happened,existence, checks sender's ownership. Amount1 + Amount2 should equal to the original minted mount of this ID. two new inscriptions will be minted as a result. the original inscription will be burned.

Burn Operation - destroy an inscription

  • Message: {"p":"nip-20", "op":"list", "tick":"<TICKER>", "id":"<ID>"}
  • Recipient: must be the owner itself
  • Validation:
    • Confirms TICKER and ID, the tx.hash where the inscription was minted,exists
    • Sender must be the owner.

List Operation - list the inscription for a price

  • Message: {"p":"nip-20", "op":"list", "tick":"<TICKER>", "id":"<ID>", "price":<number>, "unit":<UNIT>}
  • Recipient: must be the owner itself
  • Validation:
    • Confirms TICKER and ID, the tx.hash where the inscription happened,exists
    • Sender must be the owner.
    • UNIT needs to be one of the accepted unit on the deployed network. Please refer to network's page for more info. Price must be a whole number.

UnList Operation - unlist the inscription for a price

  • Message: {"p":"nip-20", "op":"ulist", "tick":"<TICKER>", "id":"<ID>"}
  • Recipient: must be the owner itself
  • Validation:
    • Confirms TICKER and ID, the tx.hash where the inscription happened,exists
    • Sender has listed the inscription.

Exchange Operation - exchange for the inscription by paying a price

  • Message: {"p":"nip-20", "op":"ex", "tick":"<TICKER>", "id":"<ID>"}
  • Recipient: must be the owner of the listed inscription.
  • Validation:
    • Confirms TICKER and ID, the tx.hash where the inscription happened,exists
    • Sender must own enough <UNIT> to pay the price. UNIT needs to be one of the accepted unit on the deployed network. Please refer to network's page for more info. Price must be a whole number.
    • The inscription was listed by the recipient.
Contract Events:
'NIP20TokenEvent_transfer(address,address,bytes32,bytes32)' - transfer from sender to recipient with ticker and id
'NIP20TokenEvent_mint(address,address,bytes32,uint256,uint256)' - mint from sender to recipient of ticker with mint id and amount. Note: require contract address set in the deployment of the token. events emitted from other contracts are ignored.
'NIP20TokenEvent_bridgeIn(address,address,address,bytes32,uint256,uint256)' - bridge erc20 in to mint a inscription
'NIP20TokenEvent_bridgeOut(address,address,address,bytes32,uint256,uint256)' - bridge inscription out for an erc20 token

Ownership Determination

  • Ownership of a token is tracked from minting. Transfer operations update ownership, with the latest valid transfer indicating the current owner.