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.

PreviousWhat's differentNextHotfix1

Last updated