Rings Tech Spec 1.0

Idea

  • The most intuitive way to facilitate fungibility on bitcoin is making the lowest denomination of a fungible asset represented by 1 satoshi. It makes it easier to understand to anyone familiar with Bitcoin. This is achievable by a fungible token standard that relies simply on verified satoshi ranges.

  • The common denominator of what traditionally gives a fungible token its value is a social consensus and it’s rarely fully trustless. Even in the case of pizza satoshis, there comes a step where you need to trust someone with a fact that’s not verifiable on chain (the fact that a certain transaction was used to purchase a pizza). For this reason, it’s way more important for the standard to be simple, clean and intuitive than it is to force extra unneeded on-chain verification steps.

  • Using a system with unique tickers or names creates a bad dynamic and promotes unhealthy squatting behavior. A different unique identifier should be used to identify different collections of fungible assets, and the ability to infinitely re-use names and tickers should not create problems.

  • There should be no obstacles for the same satoshi to be a part of any number of different collections.

  • Handling UTXOs containing the satoshis representing a certain token should be possible with any bitcoin wallet, even if the wallet is non ordinal compatible (non-taproot address).

  • Verifying satoshis or satoshi ranges as a part of the desired collection should be possible no matter what wallet they are in. This allows for free airdrops and free mints, which is a huge benefit and facilitates much easier and cheaper launches and distribution.

  • It should be possible to create mutable (keep the “mint” and “burn” authorities) and immutable (no supply or verification changes possible after the initial creation) collections.

  • During the act of new collection creation, a file should be inscribed to the bitcoin network containing the full information of the satoshis included in the collection, to facilitate an on-chain source of truth.

Technical Specification

Token Creation

This section outlines the requirements for defining a new Ring Token.

Requirements: A JSON file is the basis for defining a new token, containing

{
  "p": "rings",
  "op": "create",
  "decimals": <number>,
  // Optional properties
  "name": "<token_name>",
  "ticker": "<token_symbol>",
  "logo": {
    "type": "<url/inscriptionID>",
    "value": "<url_or_inscriptionID>"
  }
}

Required Fields:

  • p: Identifying the protocol as rings.

  • op: Operation to be performed. Here, "create" indicates that this JSON is for creating a new token.

  • decimals: Specifies the number of decimal places for the token. (e.g. 2 would mean that one verified satoshi equals 0.01 tokens)

    • Recommended maximum is 2 decimals (e.g. 2 would mean that one verified satoshi equals 0.01 tokens)

Optional Fields:

  • name: Desired token name.

    • Recommended names are between 5 and 20 characters and onoy use alphanumeric characters (A-Z, a-z, 0-9).

  • ticker: Desired token symbol.

    • Recommended tickers are 3 to 5 uppercase alphanumeric characters only.

  • logo: Contains two sub-fields:

    • type: Indicates whether the logo is stored at a URL or identified by an inscription ID.

    • value: The actual URL or inscription ID where the logo can be found.

Unique Identifier: The inscription ID of the JSON file is the unique identifier for the token/collection.

Ranges Definition:

This section specifies the ranges included within the token. The JSON structure detailed here should be inscribed as a child of the initial "create" inscription. It can be inscribed in a compressed form for efficiency.

{
  "p": "ring",
  "op": "define",
  "ranges": [
    {
      "size": 1000,
      "sat": [
        100,
        1100
      ]
    },
    {
      "size": 2000,
      "sat": [
        2100,
        4100
      ]
    }
  ],
}

Explanation of the ranges Field:

The ranges object is designed to define a specific set of satoshis associated with a token. Each element within the ranges array represents a group of satoshis. Let’s break it down:

  1. sat:

    • This field specifies the starting point of a range of satoshis, numberated by using the ordinal theory.

    • Each entry in the sat array is the first satoshi in a respective range.

  2. size:

    • This field indicates the size of the range, i.e., how many satoshis are included in the range starting from the specified sat.

    • The range is defined as [sat, sat + size), meaning it includes satoshis from the starting sat up to but not including sat + size.

    • For example, if sat is 123 and size is 1000, the range includes satoshis from 123 to 1122 (123 inclusive, 1123 exclusive).

Here is an example of how the ranges object might look:

"ranges": [
  {
    "size": 1000,
    "sat": [123, 1123]
  }
]

In this example:

  • The first range starts at satoshi 123 and includes 1000 satoshis (up to 1122).

  • The second range starts at satoshi 1123 and includes 1000 satoshis (up to 2122).

This structure allows for flexible and precise definition of satoshi ranges associated with each token, facilitating clear and straightforward token management.

Proposed UTXO Handling

For transactions under 1000 tokens, padding is required to reach 1000 satoshis.

Token Transfer

Transferring tokens involves sending a UTXO containing the appropriate amount of satoshis to another wallet.

Platform Behavior Expectations

Trading Markets

Market creation should specify:

  • Batch Size: Minimum trading size.

  • If no inscribed metadata is present, ask for Name, Ticker, and Logo.

Wallet Clients

  • Default settings should not display all rings.

  • Wallets should warn users of satoshis belonging to multiple collections.

  • Facilitate the creation of UTXOs with the desired satoshi amounts for transactions.

  • Enable users to manage their ring collections through an ID-based search.

Airdrop / Token Creation Tools

  • Assist in creating and inscribing the JSON files for collections.

  • Allow input of wallet addresses and amounts for distribution.

  • Warn users about insufficient suitable satoshis in wallets.

Examples and Notes

Example of a Token Creation JSON File:

{
  "p": "ring",
  "op": "create",
  "decimals": 0,
  "name": "ExampleToken",
  "ticker": "EXTN",
  "logo": {
    "type": "url",
    "value": "http://example.com/logo.png"
  }
}

Example of a Token Define JSON File, inscribed as a child of the Creation JSON:

{
  "p": "ring",
  "op": "define",
  "ranges": [
    {
      "size": 1000,
      "sat": [
        4500,
        5500,
        6500
      ]
    },
    {
      "size": 3000,
      "sat": [
        7500,
        11500,
        14500
      ]
    },
    {
      "size": 5000,
      "sat": [
        17500,
        22500,
        27500
      ]
    },
  ]
}

Several Extensions to the standard are already defined, like the Metadata and Mint&Burn extensions. First edition of the Tech Spec is left barebones on purpose for ease of understanding. If you have any questions or have the need to use any of the extensions sooner, please reach out.

Last updated