> For the complete documentation index, see [llms.txt](https://rings-standard.gitbook.io/rings-token-standard/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://rings-standard.gitbook.io/rings-token-standard/rings-tech-spec-1.0.md). # 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 ```json { "p": "rings", "op": "create", "decimals": , // Optional properties "name": "", "ticker": "", "logo": { "type": "", "value": "" } } ``` #### **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. ```json { "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: ```json "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**: ```json { "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**: ```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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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://rings-standard.gitbook.io/rings-token-standard/rings-tech-spec-1.0.md?ask= ``` 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.