Introduction
Ce manuel est un guide de la théorie ordinale. La théorie ordinale s’intéresse aux satoshis, leur attribuant des identités individuelles et leur permettant d’être suivis, transférés et empreints de sens.
Les satoshis, et non les bitcoins, constituent la monnaie élémentaire et native du réseau Bitcoin. Un bitcoin peut être subdivisé en 100 000 000 satoshis, mais pas plus.
La théorie ordinale ne nécessite pas de chaîne latérale ni de token autre que bitcoin et peut être utilisée sans aucune modification du réseau Bitcoin. Elle fonctionne dès maintenant.
La théorie ordinale confère aux satoshis une valeur numismatique, leur permettant d’être collectés et échangés comme des objets de curiosité.
Des satoshis individuels peuvent être inscrits avec un contenu arbitraire, créant ainsi des artefacts numériques natifs de Bitcoin uniques qui peuvent être conservés dans des portefeuilles Bitcoin et transférés à l’aide de transactions Bitcoin. Les inscriptions sont aussi durables, immuables, sécurisées et décentralisées que Bitcoin lui-même.
D’autres cas d’utilisation plus inhabituels sont possibles : des colored coins (pièces colorées) hors chaîne, une infrastructure de clés publiques avec rotation de clés, une alternative décentralisée au DNS. Pour l’instant, de tels cas d’utilisation sont spéculatifs et n’existent que dans l’esprit de théoriciens d’Ordinals marginaux.
Pour plus de détails sur la théorie ordinale, consultez l’aperçu.
Pour plus de détails sur les inscriptions, consultez la section inscriptions.
When you're ready to get your hands dirty, a good place to start is with inscriptions, a curious species of digital artifact enabled by ordinal theory.
Authors
Liens
- GitHub
- BIP
- Discord
- Site web de l’Institut Open Ordinals
- X de l’Institut Open Ordinals
- Explorateur de blocs Mainnet
- Explorateur de blocs Signet
Vidéos
- Théorie ordinale expliquée : Numéros de série de Satoshis et NFTs sur Bitcoin
- Workshop sur les Ordinals avec Rodarmor
Aperçu de la théorie ordinale
Les Ordinals sont un système de numérotation des satoshis qui permet de les suivre et de les transférer de manière individuelle. Ces numéros sont appelés numéros ordinaux. Les satoshis sont numérotés selon l’ordre dans lequel ils ont été minés et sont transférés en fonction de la séquence des transactions entrantes et sortantes, selon le principe FIFO (First In, First Out). Le système de numérotation et le système de transfert sont tous deux basés sur l’ordre séquentiel ; le système de numérotation repose sur l’ordre de minage des satoshis, tandis que le système de transfert repose sur l’ordre d’entrée et de sortie des transactions. D’où le nom ordinals.
Les détails techniques sont disponibles dans le BIP.
La théorie ordinale fonctionne dès à présent sans modification du Bitcoin et ne nécessite aucun autre token ou de chaîne latérale.
Les nombres ordinaux ont plusieurs représentations différentes:
-
Notation entière:
2099994106992659
Le nombre ordinal attribué en fonction de l’ordre dans lequel le satoshi a été miné. -
Notation décimale:
3891094.16797
Le nombre ordinal attribué en fonction de l’ordre dans lequel le satoshi a été miné. -
Notation sexagésimal:
3°111094′214″16797‴
. Nous y reviendrons dans un instant. -
Percentile notation:
99.99971949060254%
. The satoshi's position in Bitcoin's supply, expressed as a percentage. -
Nom:
satoshi
. Un encodage du nombre ordinal utilisant les caractères dea
àz
.
Des actifs arbitraires, tels que des NFTs, des tokens de sécurité, des comptes ou des stablecoins peuvent être attachés à des satoshis en utilisant des nombres ordinaux comme identifiants stables.
Ordinals est un projet open-source, développé sur GitHub. Le projet consiste en un BIP décrivant le schéma ordinal, un index qui communique avec un nœud Bitcoin Core pour suivre l’emplacement de tous les satoshis, un portefeuille qui permet d’effectuer des transactions reconnaissant les ordinals, un explorateur de blocs pour l’exploration interactive de la blockchain, une fonctionnalité permettant d’inscrire des satoshis avec des artefacts numériques, et ce manuel.
Rareté
Les humains sont des collectionneurs, et puisque les satoshis peuvent désormais être suivis et transférés, les gens voudront naturellement les collectionner. Les théoriciens d’Ordinals peuvent décider eux-mêmes quels sats sont rares et désirables, mais il existe quelques Indices…
Bitcoin connaît des événements périodiques, certains fréquents, d’autres moins communs, et ceux-ci se prêtent naturellement à un système de rareté. Ces événements périodiques sont les suivants :
-
_Blocs _: Un nouveau bloc est miné toutes les 10 minutes environ, à partir de maintenant jusqu’à la fin des temps.
-
_Ajustements de la difficulté _: Tous les 2016 blocs, soit environ toutes les deux semaines, le réseau Bitcoin réagit aux changements de taux de hachage en ajustant la cible de difficulté que les blocs doivent atteindre pour être acceptés.
-
_Halvings _: Tous les 210 000 blocs, soit environ tous les quatre ans, la quantité de nouveaux sats créés dans chaque bloc est réduite de moitié.
-
_Cycles _: Tous les six halvings, un phénomène magique se produit: la réduction de moitié et l’ajustement de la difficulté coïncident. C’est ce qu’on appelle une conjonction, et la période de temps entre les conjonctions représente un cycle. Une conjonction se produit environ tous les 24 ans. La première conjonction devrait se produire en 2032.
Cela nous donne les niveaux de rareté suivants :
commun
: Tout sat qui n’est pas le premier sat de son blocpeu commun
: Le premier sat de chaque blocrare
: Le premier sat de chaque période d’ajustement de la difficultéépique
: Le premier sat après un halvinglégendaire
: Le premier sat de chaque cyclemythique
: Le premier sat du bloc genesis
Ce qui nous amène à la notation sexagésimal, qui représente de façon non équivoque un nombre ordinal de manière qui facilite la perception de la rareté d’un satoshi :
A°B′C″D‴
│ │ │ ╰─ Index of sat in the block
│ │ ╰─── Index of block in difficulty adjustment period
│ ╰───── Index of block in halving epoch
╰─────── Cycle, numbered starting from 0
Les théoriciens d’Ordinals utilisent souvent les termes « heure », « minute », « seconde » et « tierce » en référence à A, B, C et D.
Voici quelques exemples. Ce satoshi est commun :
1°1′1″1‴
│ │ │ ╰─ Not first sat in block
│ │ ╰─── Not first block in difficulty adjustment period
│ ╰───── Not first block in halving epoch
╰─────── Second cycle
Ce satoshi est peu commun :
1°1′1″0‴
│ │ │ ╰─ First sat in block
│ │ ╰─── Not first block in difficulty adjustment period
│ ╰───── Not first block in halving epoch
╰─────── Second cycle
Ce satoshi est rare :
1°1′0″0‴
│ │ │ ╰─ First sat in block
│ │ ╰─── First block in difficulty adjustment period
│ ╰───── Not the first block in halving epoch
╰─────── Second cycle
Ce satoshi est épique :
1°0′1″0‴
│ │ │ ╰─ First sat in block
│ │ ╰─── Not first block in difficulty adjustment period
│ ╰───── First block in halving epoch
╰─────── Second cycle
Ce satoshi est légendaire :
1°0′0″0‴
│ │ │ ╰─ First sat in block
│ │ ╰─── First block in difficulty adjustment period
│ ╰───── First block in halving epoch
╰─────── Second cycle
Et ce satoshi est mythique :
0°0′0″0‴
│ │ │ ╰─ First sat in block
│ │ ╰─── First block in difficulty adjustment period
│ ╰───── First block in halving epoch
╰─────── First cycle
Si le satoshi est le premier du bloc, le zéro peut être omis. C’est l’exemple du satoshi peu commun que nous avons expliqué précédemment :
1°1′1″
│ │ ╰─ Not first block in difficulty adjustment period
│ ╰─── Not first block in halving epoch
╰───── Second cycle
Offre de Satoshis rares
Offre totale
common
: 2,099,999,990,760,000uncommon
: 6,926,535rare
: 3432epic
: 27légendaire
: 5mythique
: 1
Offre actuelle
common
: ~1.98 quadrillionuncommon
: ~880,000 (a new uncommon is mined roughly every ten minutes)rare
: ~430 (a new rare is mined roughly every two weeks)épique
: 3légendaire
: 0mythique
: 1
At the moment, even uncommon satoshis are quite rare. As of this writing, 876,023 uncommon satoshis have been mined - one per 22.6 bitcoin in circulation.
Noms
Chaque satoshi a un nom, composé des lettres A à Z, qui devient de plus en plus court au fur et à mesure que le satoshi est miné dans le futur. Ils pourraient d’abord être courts, puis devenir plus longs, mais tous les bons noms courts seraient alors piégés dans le bloc de genèse qui ne peut pas être dépensé.
À titre d’exemple, le nom pour 1905530482684727° est « iaiufjszmoba ». Le nom du dernier satoshi qui sera miné est « a ». Toutes les combinaisons de 10 caractères ou moins existent déjà, ou existeront un jour.
Exotiques
Les satoshis peuvent être prisés pour des raisons autres que leur nom ou leur rareté. Cela peut être dû à une caractéristique du nombre lui-même, comme le fait d’avoir une racine carrée ou cubique. Il peut également s’agir d’un lien avec un événement historique, tel que les satoshis du bloc 477 120, le bloc dans lequel SegWit a été activé, ou 2099999997689999°, le tout dernier satoshi qui sera miné.
Ces satoshis sont dits « exotiques ». La question de savoir quels sont les satoshis exotiques et ce qui les rend exotiques est subjective. Les théoriciens d’Ordinals sont encouragés à rechercher les exotiques sur la base de critères qu’ils auront eux-mêmes définis.
Inscriptions
Les satoshis peuvent être inscrits avec un contenu arbitraire, créant ainsi des artefacts numériques natifs de Bitcoin. L’inscription se fait en envoyant le satoshi à inscrire dans une transaction qui révèle le contenu de l’inscription sur la blockchain. Ce contenu est alors inextricablement lié à ce satoshi, le transformant en un artefact numérique immuable qui peut être suivi, transféré, thésaurisé, acheté, vendu, perdu et redécouvert.
Archéologie
Une communauté animée d’archéologues dévoués au catalogage et à la collection des premiers NFTs a vu le jour. Voici un excellent résumé des NFTs historiques par Chainleft.
Le 19 mars 2018 est généralement considéré comme la date limite pour faire référence aux premiers NFTs, car c’est ce jour-là que le premier contrat ERC-721, SU SQUARES, a été déployé sur Ethereum.
La question de savoir si les ordinals présentent un intérêt pour les archéologues des NFTs restera ouverte ! Les ordinals ont été créés au début de l’année 2022, lorsque la spécification d’Ordinals a été finalisée. En ce sens, ils ne présentent pas d’intérêt historique.
D’un autre coté par contre, les ordinals ont en fait été créés par Satoshi Nakamoto en 2009 lorsqu’il a miné le bloc de genèse de Bitcoin. En ce sens, les ordinals, et en particulier les premiers ordinals, suscitent certainement un intérêt historique.
De nombreux théoriciens d’Ordinals préfèrent cette dernière perspective. Cela tient en partie au fait que les ordinals ont été découverts indépendamment au moins à deux reprises, bien avant l’ère des NFTs modernes.
Le 21 août 2012, Charlie Lee a publié une proposition visant à ajouter un Proof of Stake (PoS) à Bitcoin sur le forum Bitcoin Talk. Il ne s’agissait pas d’un système d’actifs, mais sa proposition utilisait néanmoins l’algorithme ordinal et a été mise en œuvre, mais n’a jamais été déployée.
Le 8 octobre 2012, jl2012 a publié un schéma sur le même Forum qui utilise une notation décimale et possède toutes les propriétés importantes des ordinals. Le schéma a été discuté mais jamais mis en œuvre.
D’une certaine manière, ces inventions indépendantes d’ordinals indiquent que les ordinals ont été découverts, ou redécouverts, et non pas inventés. Les ordinals sont une conséquence inévitable de la mathématique de Bitcoin, qui découle non pas de leur documentation moderne, mais de leur genèse ancienne. Ils sont l’aboutissement d’une séquence d’événements qui se sont déroulés au fil des ans et qui ont commencé lorsque le premier bloc a été miné.
Artéfacts numériques
Imaginez un artefact physique. Disons, une pièce rare, conservée en sécurité pendant d’innombrables années dans la cachette sombre et secrète d’un trésor Viking, que vous déterrez aujourd’hui de vos propres mains. Cette pièce…
...a un propriétaire. Vous. Tant que vous la gardez en sécurité, personne ne peut vous le prendre.
...est complète. Il n’y a aucune partie manquante.
…ne peut être modifiée que par vous. Si vous étiez un marchand et que vous arriviez en Chine au XVIIIe siècle, vous seul pourriez la marquer de votre poinçon.
…ne peut être transmise que par vous. C’est à vous qu’appartient la décision de la vendre, de l’échanger ou de la donner, à qui vous voulez.
Que sont les artefacts numériques ? Il s’agit tout simplement de l’équivalent numérique des artefacts physiques.
Pour qu’une chose numérique soit un artefact numérique, elle doit être comme votre pièce de monnaie :
-
Les artefacts numériques peuvent avoir des propriétaires. Un nombre n’est pas un artefact numérique, car personne ne peut le posséder.
-
Les artefacts numériques sont complets. Un NFT qui pointe vers un contenu hors chaîne sur IPFS ou Arweave est incomplet et n’est donc pas un artefact numérique.
-
Les artefacts numériques sont sans permission. Un NFT qui ne peut être vendu sans avoir à payer des redevances n’est pas sans permission et n’est donc pas un artefact numérique.
-
Les artefacts numériques ne sont pas censurables. Il peut être possible de modifier des informations dans une base de données centralisée aujourd’hui, mais ça ne sera peut-être plus possible demain, et il ne peut donc s’agir d’un artefact numérique.
-
Les artefacts numériques sont immuables. Un NFT avec une clé de mise à jour n’est pas un artefact numérique.
La définition d’un artefact numérique vise à refléter ce que les NFTs devraient être, ce qu’ils sont parfois et ce que les inscriptions seront toujours, de par leur nature même.
Inscriptions
Les inscriptions inscrivent des sats avec un contenu arbitraire, créant ainsi des artefacts numériques natifs de Bitcoin, plus communément appelés NFTs. Les inscriptions ne nécessitent pas de chaîne latérale ou de token séparé.
Ces sats inscrits peuvent ensuite être transférés au moyen de transactions Bitcoin, envoyés à des adresses Bitcoin et détenus dans des UTXOs (sorties de transactions non dépensées) Bitcoin. Tous ces processus sont exécutés comme ils le sont normalement dans Bitcoin, à l’exception du fait que, pour envoyer des satoshis individuels, les transactions doivent contrôler l’ordre et la valeur des entrées et des sorties conformément à la théorie ordinale.
Le modèle de contenu fonctionne de manière similaire à celui du web. Une inscription se compose d’un type de contenu, également connu sous le nom de type MIME, et du contenu lui-même, qui est une chaîne d’octets. Cela permet de récupérer le contenu de l’inscription à partir d’un serveur web et de créer des entrées HTML qui utilisent le contenu d’autres inscriptions.
Le contenu de l’inscription est entièrement sur la blockchain, stocké dans des scripts taproot (taproot script-path spend scripts). Les scripts taproot ont très peu de restrictions sur ce qu’ils peuvent contenir, et ils bénéficient également de la réduction pour témoins, ce qui rend le stockage du contenu de l’inscription relativement peu coûteux.
Étant donné que les dépenses de script taproot (taproot script spends) ne peuvent être effectuées qu’à partir de sorties taproot existantes, les inscriptions sont réalisées à l’aide d’une procédure d’engagement/de révélation en deux phases. Tout d’abord, dans la transaction d’engagement, une sortie de script taproot est créée qui s’engage à un script contenant le contenu de l’inscription. Ensuite, dans la transaction de révélation, la sortie créée par la transaction d’engagement est dépensée, révélant le contenu de l’inscription sur la blockchain.
Le contenu de l’inscription est sérialisé à l’aide de push de données dans des structures conditionnelles non exécutées, appelées « enveloppes ». Les enveloppes se composent d’un OP_FALSE OP_IF … OP_ENDIF
enveloppant un nombre quelconque de push de données. Parce que les enveloppes sont effectivement des opérations nulles, elles ne modifient pas la sémantique du script dans lequel elles sont incluses et peuvent être combinées avec n’importe quel autre script de verrouillage.
Une inscription textuelle contenant la chaîne « Hello, world! » est sérialisée comme suit :
OP_FALSE
OP_IF
OP_PUSH "ord"
OP_PUSH 1
OP_PUSH "text/plain;charset=utf-8"
OP_PUSH 0
OP_PUSH "Hello, world!"
OP_ENDIF
Tout d’abord, un push est fait avec la chaîne ord
pour distinguer les inscriptions des autres utilisations des enveloppes.
OP_PUSH 1
indique que le prochain push contient le type de contenu, et OP_PUSH 0
indique que les données suivantes dans le push contiennent le contenu lui-même. Plusieurs pushs de données doivent être utilisés pour les inscriptions volumineuses, car l’une des rares restrictions de taproot est qu’un push de données ne peut pas dépasser 520 octets.
The inscription content is contained within the input of a reveal transaction, and the inscription is made on the first sat of its input if it has no pointer field. This sat can then be tracked using the familiar rules of ordinal theory, allowing it to be transferred, bought, sold, lost to fees, and recovered.
Contenu
Le modèle de données pour les inscriptions est celui d’une réponse HTTP, permettant au contenu de l’inscription d’être récupéré via un serveur web et affiché dans un navigateur web.
Champs
Les entrées peuvent inclure des champs avant un corps optionnel. Chaque champ se compose de deux pushs de données, une étiquette et une valeur.
Currently, there are six defined fields:
content_type
, with a tag of1
, whose value is the MIME type of the body.pointer
, with a tag of2
, see pointer docs.parent
, with a tag of3
, see provenance.metadata
, with a tag of5
, see metadata.metaprotocol
, with a tag of7
, whose value is the metaprotocol identifier.content_encoding
, with a tag of9
, whose value is the encoding of the body.delegate
, with a tag of11
, see delegate.
Le début du corps et la fin des champs sont indiqués par un push de données vide.
Les étiquettes non reconnues sont interprétées différemment en fonction de leur caractère pair ou impair, conformément à la règle « il est acceptable d’être impair » utilisée par le réseau Lightning.
Les étiquettes paires sont utilisées pour les champs qui peuvent affecter la création, l’assignation initiale ou le transfert d’une inscription. Par conséquent, les inscriptions avec des champs pairs non reconnus doivent être affichées comme « non liées », c’est-à-dire sans emplacement.
Les étiquettes impaires sont utilisées pour les champs qui n’affectent pas la création, l’attribution initiale ou le transfert, tels que les métadonnées supplémentaires, et peuvent donc être ignorées en toute sécurité.
IDs des inscriptions
Les inscriptions sont contenues dans les entrées d’une transaction de révélation. Pour les identifier, on leur attribue un identifiant comme celui-ci :
521f8eccffa4c41a3a7728dd012ea5a4a02feed81f41159231251ecf1e5c79dai0
La partie précédant le i
est l’identifiant de transaction (txid
) de la transaction de révélation. Le nombre après le i
définit l’indice (commençant à 0) des nouvelles inscriptions effectuées dans la transaction de révélation.
Les inscriptions peuvent se trouver dans des entrées différentes, dans la même entrée ou une combinaison des deux. Dans tous les cas, l’ordre est clair, car un analyseur syntaxique parcourrait les entrées de manière consécutive et rechercherait toutes les enveloppes
d’inscription.
Entrée | Nombre d’inscriptions | Indices |
---|---|---|
0 | 2 | i0, i1 |
1 | 1 | i2 |
2 | 3 | i3, i4, i5 |
3 | 0 | |
4 | 1 | i6 |
Inscription Numbers
Inscriptions are assigned inscription numbers starting at zero, first by the order reveal transactions appear in blocks, and the order that reveal envelopes appear in those transactions.
Due to a historical bug in ord
which cannot be fixed without changing a great many inscription numbers, inscriptions which are revealed and then immediately spent to fees are numbered as if they appear last in the block in which they are revealed.
Inscriptions which are cursed are numbered starting at negative one, counting down. Cursed inscriptions on and after the jubilee at block 824544 are vindicated, and are assigned positive inscription numbers.
Sandbox
Les inscriptions HTML et SVG sont placées dans un environnement isolé (sandbox) afin d’empêcher les références à des contenus hors chaîne, ce qui permet de maintenir les inscriptions immuables et autonomes, c’est-à-dire contenues dans l’environnement.
Pour ce faire, les entrées HTML et SVG sont chargées dans des iframes
avec l’attribut sandbox
et la stratégie de sécurité Content-Security-Policy
est ajoutée aux en-têtes.
Self-Reference
The content of the inscription with ID INSCRIPTION_ID
must served from the URL path /content/<INSCRIPTION_ID>
.
This allows inscriptions to retrieve their own inscription ID with:
let inscription_id = window.location.pathname.split("/").pop();
If an inscription with ID X delegates to an inscription with ID Y, that is to say, if inscription X contains a delegate field with value Y, the content of inscription X must be served from the URL path /content/X
, not /content/Y
.
This allows delegating inscriptions to use their own inscription ID as a seed for generative delegate content.
Reinscriptions
Previously inscribed sats can be reinscribed with the --reinscribe
command if the inscription is present in the wallet. This will only append an inscription to a sat, not change the initial inscription.
Reinscribe with satpoint: ord wallet inscribe --fee-rate <FEE_RATE> --reinscribe --file <FILE> --satpoint <SATPOINT>
Reinscribe on a sat (requires sat index): ord --index-sats wallet inscribe --fee-rate <FEE_RATE> --reinscribe --file <FILE> --sat <SAT>
Burning
Inscriptions may be burned by constructing a transaction that spends them to a script pubkey beginning with OP_RETURN
.
Sending inscriptions to a so-called "burn address" is not recognized by ord
.
Burned inscriptions receive the "burned" charm, recognized with 🔥 on the inscription's /inscription
page.
When burning inscriptions, CBOR metadata may be included in a data push immediately following the OP_RETURN
.
Burn metadata is unstructured, having no meaning to the underlying protocol, and should be human readable. It is displayed on the burned inscription's /inscription
page, in the same manner as inscription metadata, under the heading "burn metadata".
Use it, if you feel like it, to commemorate the inscription, celebrate the closing of a collection, or for whatever other purposes you so desire.
Data pushes after the first are currently ignored by ord
. However, they may be given future meaning by the protocol, and should not be used.
For example, transaction b42f0d8a3277ce6a7e564fec8f5579f76bc19cb24f8eff565ebb81a4c2f94683 burned inscription 681b5373c03e3f819231afd9227f54101395299c9e58356bda278e2f32bef2cdi0.
Delegate
Inscriptions may nominate a delegate inscription. Requests for the content of an inscription with a delegate will instead return the content, content type and content encoding of the delegate. This can be used to cheaply create copies of an inscription.
Spécification
To create an inscription I with delegate inscription D:
- Create an inscription D. Note that inscription D does not have to exist when making inscription I. It may be inscribed later. Before inscription D is inscribed, requests for the content of inscription I will return a 404.
- Include tag
11
, i.e.OP_PUSH 11
, in I, with the value of the serialized binary inscription ID of D, serialized as the 32-byteTXID
, followed by the four-byte little-endianINDEX
, with trailing zeroes omitted.
N.B. Les octets de l’identifiant d’une transaction Bitcoin sont inversés dans leur représentation textuelle, de sorte que l’identifiant de la transaction sérialisée sera dans l’ordre inverse.
Exemple
An example of an inscription which delegates to 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1fi0
:
OP_FALSE
OP_IF
OP_PUSH "ord"
OP_PUSH 11
OP_PUSH 0x1f1e1d1c1b1a191817161514131211100f0e0d0c0b0a09080706050403020100
OP_ENDIF
Note that the value of tag 11
is decimal, not hex.
The delegate field value uses the same encoding as the parent field. See provenance for more examples of inscription ID encodings
See examples for on-chain examples of inscriptions that feature this functionality.
Métadonnées
Les inscriptions peuvent inclure des métadonnées CBOR, stockées sous forme de pushs de données dans des champs avec étiquette 5
. Vu que les pushs de données sont limités à 520 octets, les métadonnées de plus de 520 octets doivent être divisées en plusieurs champs avec étiquette 5
, qui seront ensuite concaténés avant le décodage.
Les métadonnées sont lisibles par l’humain, et toutes les métadonnées seront affichées à l’utilisateur avec son inscription. Les inscripteurs sont encouragés à réfléchir à la manière dont les métadonnées seront affichées et à les rendre concises et attrayantes.
Les métadonnées sont converties en HTML pour être affichées de la manière suivante :
null
(nul),true
(vrai),false
(faux), les nombres, les éléments flottants (floats) et les chaînes de caractères (strings) sont rendus en texte brut.- Les chaînes d’octets sont rendues sous forme hexadécimale majuscule.
- Les tableaux (arrays) sont rendus en étiquettes
<ul>
, chaque élément étant encadré par des étiquettes<li>
. - Les tableaux associatifs (maps) sont rendus sous forme d’étiquettes
<dl>
, chaque clé étant encadrée par des étiquettes<dt>
et chaque valeur étant encadrée par des étiquettes<dd>
. - Les étiquettes sont rendues sous forme de l'étiquette, encadrées par une étiquette
<sup>
, suivie de la valeur.
CBOR est une spécification complexe qui comporte de nombreux types de données différents et de multiples façons de représenter les mêmes données. Les types de données exotiques, tels que les étiquettes, les éléments flottants et les bignums, ainsi que les encodages tels que les valeurs indéfinies, peuvent ne pas s’afficher correctement, voire pas du tout. Les contributions à ord
visant à remédier à ce problème sont les bienvenues.
Exemple
Le CBOR n’étant pas lisible par l’humain, il est représenté sous forme de JSON dans les exemples suivants. Gardez à l’esprit que cela est uniquement pour ces exemples, et que les métadonnées JSON ne seront pas affichées correctement.
Les métadonnées {"foo":"bar","baz":[null,true,false,0]}
seraient incluses dans une inscription sous la forme suivante :
OP_FALSE
OP_IF
...
OP_PUSH 0x05 OP_PUSH '{"foo":"bar","baz":[null,true,false,0]}'
...
OP_ENDIF
Et rendues comme suit :
<dl>
...
<dt>metadata</dt>
<dd>
<dl>
<dt>foo</dt>
<dd>bar</dd>
<dt>baz</dt>
<dd>
<ul>
<li>null</li>
<li>true</li>
<li>false</li>
<li>0</li>
</ul>
</dd>
</dl>
</dd>
...
</dl>
Les métadonnées de plus de 520 octets doivent être divisées en plusieurs champs :
OP_FALSE
OP_IF
...
OP_PUSH 0x05 OP_PUSH '{"very":"long","metadata":'
OP_PUSH 0x05 OP_PUSH '"is","finally":"done"}'
...
OP_ENDIF
Which would then be concatenated into {"very":"long","metadata":"is","finally":"done"}
.
See examples for on-chain examples of inscriptions that feature this functionality.
Pointer
In order to make an inscription on a sat other than the first of its input, a zero-based integer, called the "pointer", can be provided with tag 2
, causing the inscription to be made on the sat at the given position in the outputs. If the pointer is equal to or greater than the number of total sats in the outputs of the inscribe transaction, it is ignored, and the inscription is made as usual. The value of the pointer field is a little endian integer, with trailing zeroes ignored.
An even tag is used, so that old versions of ord
consider the inscription to be unbound, instead of assigning it, incorrectly, to the first sat.
This can be used to create multiple inscriptions in a single transaction on different sats, when otherwise they would be made on the same sat.
Examples
An inscription with pointer 255:
OP_FALSE
OP_IF
OP_PUSH "ord"
OP_PUSH 1
OP_PUSH "text/plain;charset=utf-8"
OP_PUSH 2
OP_PUSH 0xff
OP_PUSH 0
OP_PUSH "Hello, world!"
OP_ENDIF
An inscription with pointer 256:
OP_FALSE
OP_IF
OP_PUSH "ord"
OP_PUSH 1
OP_PUSH "text/plain;charset=utf-8"
OP_PUSH 2
OP_PUSH 0x0001
OP_PUSH 0
OP_PUSH "Hello, world!"
OP_ENDIF
An inscription with pointer 256, with trailing zeroes, which are ignored:
OP_FALSE
OP_IF
OP_PUSH "ord"
OP_PUSH 1
OP_PUSH "text/plain;charset=utf-8"
OP_PUSH 2
OP_PUSH 0x000100
OP_PUSH 0
OP_PUSH "Hello, world!"
OP_ENDIF
Properties
Inscriptions may include CBOR properties, stored as data pushes in fields with tag 17
. Since data pushes are limited to 520 bytes, CBOR longer than 520 bytes must be split into multiple tag 17
fields, which will then be concatenated before decoding.
Properties are a structured counterpart to metadata. While metadata may contain arbitrary CBOR which has no protocol-defined meaning and is presented on /inscription
as HTML, properties have protocol-defined meaning and must conform to a strict schema.
Indefinite-length types are not supported. All maps, arrays, byte strings, and text strings must be definite.
The non-normative CDDL schema of the properties value is as follows:
Properties = {
? 0: [*GalleryItem],
* any => any,
}
GalleryItem = {
? 0: bstr .size (32..36),
* any => any,
}
The above CDDL schema is provided as a convenience. As always, the ordinals reference implementation ord
is the normative specification of inscriptions, and thus the properties field.
Fields matching the * any => any
wildcard must be ignored, for compatibility with future additions.
Galleries
Inscriptions whose properties field contains GalleryItem
s are galleries.
Galleries contain GalleryItem
s, whose only defined key 0
contains a serialized inscription ID. Inscription ID TXIDiINDEX
is serialized as a byte string containing the 32 byte TXID, concatenated with by the four-byte little-endian INDEX
. Trailing zeros may be removed from four-byte INDEX
, so IDs ending in i0
may be serialized in 32 bytes.
Gallery items are displayed on the inscriptions /inscription
page on the explorer.
Galleries are similar to children, in that they provide a way to create collections of inscriptions. However, galleries are permissionless. Anyone may create a gallery including any inscriptions. Thus, inclusion in a gallery does not imply provenance. Additionally, because of this, inclusion in a gallery does not create a backlink from the gallery item's /inscription
page to the gallery.
Galleries may be created when batch inscribing with ord wallet batch
by including an array of string inscription IDs of under the gallery
key of the inscription entry in the batch file, or when using ord wallet inscribe
using the --gallery
option.
Provenance
Le propriétaire d’une inscription peut créer des inscriptions enfants, en établissant d’une manière trustless (sans confiance) la provenance de ces enfants sur la blockchain comme ayant été créés par le propriétaire de l’inscription parent. Cela peut être utilisé pour les collections, de façon à ce que les enfants d’une inscription parent soient membres de la même collection.
Les enfants peuvent avoir des enfants, ce qui permet de créer des hiérarchies complexes. Par exemple, un artiste peut créer une inscription le représentant, avec des sous-inscriptions représentant les collections qu’il a créées, les enfants de ces sous-inscriptions étant des éléments de ces collections.
Spécification
Pour créer une inscription enfant C avec une inscription parent P :
- Créez une transaction d’inscription T comme d’habitude pour C.
- Dépensez le parent P dans l’une des entrées de T.
- Incluez l’étiquette
3
, c’est-à-direOP_PUSH 3
, dans C, avec la valeur de l’identifiant binaire sérialisé de l’inscription P, sérialisé avec leTXID
de 32 octets, suivi de l’INDEX
en format petit-boutien de quatre octets, en omettant les zéros de fin.
N.B. Les octets de l’identifiant d’une transaction Bitcoin sont inversés dans leur représentation textuelle, de sorte que l’identifiant de la transaction sérialisée sera dans l’ordre inverse.
Exemple
Exemple d’une inscription enfant de 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1fi0
:
OP_FALSE
OP_IF
OP_PUSH "ord"
OP_PUSH 1
OP_PUSH "text/plain;charset=utf-8"
OP_PUSH 3
OP_PUSH 0x1f1e1d1c1b1a191817161514131211100f0e0d0c0b0a09080706050403020100
OP_PUSH 0
OP_PUSH "Hello, world!"
OP_ENDIF
Notez que la valeur de l’étiquette 3
est binaire, et non hexadécimale, et que pour que l’inscription enfant soit reconnue comme telle, 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1fi0
doit être dépensé comme l’une des entrées de la transaction d’inscription.
Exemple de codage de l’inscription contenant l’ID 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1fi255
:
OP_FALSE
OP_IF
…
OP_PUSH 3
OP_PUSH 0x1f1e1d1c1b1a191817161514131211100f0e0d0c0b0a09080706050403020100ff
…
OP_ENDIF
Et de l’inscription contenant l’ID 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1fi256
:
OP_FALSE
OP_IF
…
OP_PUSH 3
OP_PUSH 0x1f1e1d1c1b1a191817161514131211100f0e0d0c0b0a090807060504030201000001
…
OP_ENDIF
Notes
L’étiquette 3
est utilisée parce que c’est la première étiquette impaire disponible. Les étiquettes impaires inconnues ne dissocient pas les inscriptions, de sorte que les inscriptions enfants seraient reconnues et suivies par les anciennes versions d’ord
.
Une collection peut être fermée en brûlant l’inscription parent de la collection, ce qui garantit qu’aucune autre pièce ne peut être émise dans la collection.
See examples for on-chain examples of inscriptions that feature this functionality.
Récursion
An important exception to sandboxing is recursion. Recursive endpoints are whitelisted endpoints that allow access to on-chain data, including the content of other inscriptions.
Since changes to recursive endpoints might break inscriptions that rely on them, recursive endpoints have backwards-compatibility guarantees not shared by ord server
's other endpoints. In particular:
- Recursive endpoints will not be removed
- Object fields returned by recursive endpoints will not be renamed or change types
However, additional object fields may be added or reordered, so inscriptions must handle additional, unexpected fields, and must not expect fields to be returned in a specific order.
Recursion has a number of interesting use-cases:
-
Combiner le contenu des inscriptions existantes.
-
Publier des extraits de code, des images, des fichiers audio ou des feuilles de style (stylesheet) en tant que ressources publiques partagées.
-
Collections d’art génératif où un algorithme est inscrit en JavaScript, et instancié à partir de multiples inscriptions avec semences uniques.
-
Collections d’images de profil génératives où les accessoires et les attributs sont inscrits en tant qu’images individuelles ou dans un atlas de textures partagé, puis combinés, à la manière d’un collage, dans des combinaisons uniques dans plusieurs inscriptions.
Endpoints
GET
/content/<INSCRIPTION_ID>
Description
The content of the inscription with <INSCRIPTION_ID>
.
Exemple
curl -s \
http://0.0.0.0:80/content/6fb976ab49dcec017f1e201e84395983204ae1a7c2abf7ced0a85d692e442799i0 > skull.jpg
no terminal output, just file creation
GET
/r/blockhash
Description
Latest block hash.
Exemple
curl -s \
http://0.0.0.0:80/r/blockhash
"00000000000000000002891b440944e0ce40b37b6ccaa138c280e9edfc319d5d"
GET
/r/blockhash/<HEIGHT>
Description
Block hash at given block height as JSON string.
Exemple
curl -s \
http://0.0.0.0:80/r/blockhash/840000
"0000000000000000000320283a032748cef8227873ff4872689bf23f1cda83a5"
GET
/r/blockheight
Description
Latest block height.
Exemple
curl -s \
http://0.0.0.0:80/r/blockheight
866393
GET
/r/blockinfo/<QUERY>
Description
Block info. <QUERY>
may be a block height or block hash.
Example (blockheight)
curl -s \
http://0.0.0.0:80/r/blockinfo/0
{
"average_fee": 0,
"average_fee_rate": 0,
"bits": 486604799,
"chainwork": "0000000000000000000000000000000000000000000000000000000100010001",
"confirmations": 866396,
"difficulty": 1.0,
"hash": "000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f",
"feerate_percentiles": [
0,
0,
0,
0,
0
],
"height": 0,
"max_fee": 0,
"max_fee_rate": 0,
"max_tx_size": 0,
"median_fee": 0,
"median_time": 1231006505,
"merkle_root": "4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b",
"min_fee": 0,
"min_fee_rate": 0,
"next_block": "00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048",
"nonce": 2083236893,
"previous_block": null,
"subsidy": 5000000000,
"target": "00000000ffff0000000000000000000000000000000000000000000000000000",
"timestamp": 1231006505,
"total_fee": 0,
"total_size": 0,
"total_weight": 0,
"transaction_count": 1,
"version": 1
}
Example (blockhash)
curl -s \
http://0.0.0.0:80/r/blockinfo/0000000000000000000320283a032748cef8227873ff4872689bf23f1cda83a5
{
"average_fee": 1234031,
"average_fee_rate": 3770,
"bits": 386089497,
"chainwork": "0000000000000000000000000000000000000000753bdab0e0d745453677442b",
"confirmations": 26397,
"difficulty": 86388558925171.02,
"hash": "0000000000000000000320283a032748cef8227873ff4872689bf23f1cda83a5",
"feerate_percentiles": [
108,
134,
200,
350,
1063
],
],
"height": 840000,
"height": 840000,
"max_fee": 799987800,
"max_fee_rate": 3604819,
"max_tx_size": 166989,
"median_fee": 34800,
"median_fee": 34800,
"median_time": 1713570208,
"merkle_root": "031b417c3a1828ddf3d6527fc210daafcc9218e81f98257f88d4d43bd7a5894f",
"min_fee": 2060,
"min_fee_rate": 15,
"next_block": "00000000000000000001b48a75d5a3077913f3f441eb7e08c13c43f768db2463",
"nonce": 3932395645,
"previous_block": "0000000000000000000172014ba58d66455762add0512355ad651207918494ab",
"subsidy": 312500000,
"target": "0000000000000000000342190000000000000000000000000000000000000000",
"timestamp": 1713571767,
"total_fee": 3762561499,
"total_size": 2325218,
"total_weight": 3991793,
"transaction_count": 3050,
"version": 710926336
}
GET
/r/blocktime
Description
UNIX time stamp of latest block.
Exemple
curl -s \
http://0.0.0.0:80/r/blocktime
1729362253
GET
/r/children/<INSCRIPTION_ID>
Description
The first 100 child inscription ids.
Exemple
curl -s \
http://0.0.0.0:80/r/children/e317a2a5d68bd1004ae15a06175a319272a10389ff125c98820389edef8b0a94i0
{
"ids": [
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei0",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei1",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei2",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei3",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei4",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei5",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei6",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei7",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei8",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei9",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei10",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei11",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei12",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei13",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei14",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei15",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei16",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei17",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei18",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei19",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei20",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei21",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei22",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei23",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei24",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei25",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei26",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei27",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei28",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei29",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei30",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei31",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei32",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei33",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei34",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei35",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei36",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei37",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei38",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei39",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei40",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei41",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei42",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei43",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei44",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei45",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei46",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei47",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei48",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei49",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei50",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei51",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei52",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei53",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei54",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei55",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei56",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei57",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei58",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei59",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei60",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei61",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei62",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei63",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei64",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei65",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei66",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei67",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei68",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei69",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei70",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei71",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei72",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei73",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei74",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei75",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei76",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei77",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei78",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei79",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei80",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei81",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei82",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei83",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei84",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei85",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei86",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei87",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei88",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei89",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei90",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei91",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei92",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei93",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei94",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei95",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei96",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei97",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei98",
"89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei99"
],
"more": true,
"page": 0
}
GET
/r/children/<INSCRIPTION_ID>/<PAGE>
Description
The set of 100 child inscription ids on <PAGE>
.
Exemple
curl -s \
http://0.0.0.0:80/r/children/e317a2a5d68bd1004ae15a06175a319272a10389ff125c98820389edef8b0a94i0/9
{
"ids": [
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci60",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci61",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci62",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci63",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci64",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci65",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci66",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci67",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci68",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci69",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci70",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci71",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci72",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci73",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci74",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci75",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci76",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci77",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci78",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci79",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci80",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci81",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci82",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci83",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci84",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci85",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci86",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci87",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci88",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci89",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci90",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci91",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci92",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci93",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci94",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci95",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci96",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci97",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci98",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci99",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci100",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci101",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci102",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci103",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci104",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci105",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci106",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci107",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci108",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci109",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci110",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci111",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci112",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci113",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci114",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci115",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci116",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci117",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci118",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci119",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci120",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci121",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci122",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci123",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci124",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci125",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci126",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci127",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci128",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci129",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci130",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci131",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci132",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci133",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci134",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci135",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci136",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci137",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci138",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci139",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci140",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci141",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci142",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci143",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci144",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci145",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci146",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci147",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci148",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci149",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci150",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci151",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci152",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci153",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci154",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci155",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci156",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci157",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci158",
"b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci159"
],
"more": true,
"page": 9
}
GET
/r/children/<INSCRIPTION_ID>/inscriptions
Description
Details of first 100 child inscriptions of INSCRIPTION_ID
.
Exemple
curl -s \
http://0.0.0.0:80/r/children/e317a2a5d68bd1004ae15a06175a319272a10389ff125c98820389edef8b0a94i0/inscriptions
{
"children": [
{
"charms": [],
"fee": 417,
"height": 861224,
"id": "89e4fb2e5ea5c6301b9ac915d1d05619776f5ca41fc02fb6e5dced16f2cabfdei0",
"number": 75744297,
"output": "236ce10d9cd3f9f7f824a07686f7d7bce0d64a400f0328ce5bb2191a60d15262:0",
"sat": null,
"satpoint": "236ce10d9cd3f9f7f824a07686f7d7bce0d64a400f0328ce5bb2191a60d15262:0:0",
"timestamp": 1726282054
},
...
],
"more": true,
"page": 0
}
GET
/r/children/<INSCRIPTION_ID>/inscriptions/<PAGE>
Description
Details of 100 child inscriptions of INSCRIPTION_ID
paginated by PAGE
.
Exemple
curl -s \
http://0.0.0.0:80/r/children/e317a2a5d68bd1004ae15a06175a319272a10389ff125c98820389edef8b0a94i0/inscriptions/9
{
"children": [
{
"charms": [
"vindicated"
],
"fee": 418,
"height": 861239,
"id": "b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci60",
"number": 75750346,
"output": "e8ebadbd9ce4e4372b1b9b30fd5cb831c1f48ff2d0f8f1d1de2e190a2f5bcbe8:1",
"sat": null,
"satpoint": "e8ebadbd9ce4e4372b1b9b30fd5cb831c1f48ff2d0f8f1d1de2e190a2f5bcbe8:1:0",
"timestamp": 1726292222
},
{
"charms": [
"vindicated"
],
"fee": 418,
"height": 861239,
"id": "b205c9d1dc054f24c13aeb886fba42d9dd0aac3cd9bdc4f034affc90f3a0bf3ci61",
"number": 75750347,
"output": "aa46f14bec8842edd7b7c1b79224cd186dda6c5577cd65196da77d7e27b00b0c:0",
"sat": null,
"satpoint": "aa46f14bec8842edd7b7c1b79224cd186dda6c5577cd65196da77d7e27b00b0c:0:0",
"timestamp": 1726292222
},
...
],
"more": true,
"page": 9
}
GET
/r/inscription/<INSCRIPTION_ID>
Description
Information about an inscription.
Exemple
curl -s \
http://0.0.0.0:80/r/inscriptions/13130e4b299ed361f2a734f6433844ef0f0211cd504e0ca8f4d4ab20f51b8127i0
{
"charms": [
"vindicated"
],
"content_type": "model/gltf-binary",
"content_length": 3726620,
"delegate": null,
"fee": 7499396,
"height": 866266,
"id": "13130e4b299ed361f2a734f6433844ef0f0211cd504e0ca8f4d4ab20f51b8127i0",
"number": 76545890,
"output": "13130e4b299ed361f2a734f6433844ef0f0211cd504e0ca8f4d4ab20f51b8127:1",
"sat": null,
"satpoint": "13130e4b299ed361f2a734f6433844ef0f0211cd504e0ca8f4d4ab20f51b8127:1:0",
"timestamp": 1729297535,
"value": 1313,
"address": "bc1phj8hgzeptthkur9se2jq5vex7vlyhc8ul689svxea0xsn6r43z7sekz6qh"
}
GET
/r/metadata/<INSCRIPTION_ID>
Description
JSON string containing the hex-encoded CBOR metadata.
Exemple
curl -s \
http://0.0.0.0:80/r/metadata/b1ef66c2d1a047cbaa6260b74daac43813924378fe08ef8545da4cb79e8fcf00i0
"ac6c50484f544f475241504845526a5041524b4552204441596643414d4552416c43414e4f4e20454f532d31566446494c4d6f4b4f44414b20454b54415220313030644c454e53781a5a4549535320504c414e415220542a2038354d4d20462f312e346d5348555454455220535045454465312f31323568415045525455524563462f38664d4f44454c5318646650484f544f531903e8684c4f434154494f4e774c4f5320414e47454c45532c2043414c49464f524e49416443524557a36a415353495354414e4345826e41524941532042555244454c4c49684e4153204e495858664d414b45555087754544454e2053594d4f4e45204c415454414e5a494f6a4d494d49204d455945526e53414d414e544841204c455052456f4c4953455454452053414e54414e416e4a45535349434120564552474f4e63504f4e724d415941204e414b415241205352554f4348644841495283694a414b4920494348556c4a4f43454c594e2056454741724a4546464552534f4e2054414e475241444966504154524f4e6e434153455920524f4441524d4f52674c4943454e534563434330"
GET
/r/parents/<INSCRIPTION_ID>
Description
The first 100 parent inscription ids.
Exemple
curl -s \
http://0.0.0.0:80/r/parents/b1ef66c2d1a047cbaa6260b74daac43813924378fe08ef8545da4cb79e8fcf00i0
{
"ids": [
"6fb976ab49dcec017f1e201e84395983204ae1a7c2abf7ced0a85d692e442799i0"
],
"more": false,
"page_index": 0
}
GET
/r/parents/<INSCRIPTION_ID>/<PAGE>
Description
The set of 100 parent inscription ids on <PAGE>
.
Exemple
curl -s \
http://0.0.0.0:80/r/parents/b1ef66c2d1a047cbaa6260b74daac43813924378fe08ef8545da4cb79e8fcf00i0/9
{
"ids": [],
"more": false,
"page_index": 9
}
GET
/r/parents/<INSCRIPTION_ID>/inscriptions
Description
Details of the first 100 parent inscriptions.
Exemple
curl -s -H "Accept: application/json" \
http://0.0.0.0:80/r/parents/4a86d375a70a4ecc7ffcd910e05f5e0771ae6a50133543f1bf6b5651adbf0019i0/inscriptions
{
"parents": [
{
"charms": [],
"fee": 21730,
"height": 775167,
"id": "92c409fb749b1005fe9a1482d3a74a8e73936a72644f4979df8184aba473841di0",
"number": 4573,
"output": "4a86d375a70a4ecc7ffcd910e05f5e0771ae6a50133543f1bf6b5651adbf0019:13",
"sat": null,
"satpoint": "4a86d375a70a4ecc7ffcd910e05f5e0771ae6a50133543f1bf6b5651adbf0019:13:0",
"timestamp": 1675607405
},
{
"charms": [],
"fee": 14977,
"height": 775167,
"id": "c689cbcb8e31858c5e1476d04af4e7e7cedd1fb4fb9cae5bb62036936a08282di0",
"number": 4576,
"output": "4a86d375a70a4ecc7ffcd910e05f5e0771ae6a50133543f1bf6b5651adbf0019:14",
"sat": null,
"satpoint": "4a86d375a70a4ecc7ffcd910e05f5e0771ae6a50133543f1bf6b5651adbf0019:14:0",
"timestamp": 1675607405
},
{
"charms": [],
"fee": 12533,
"height": 775167,
"id": "982d15f6b3510307ef845f1cb3352b27e2b048616b7c0642367ebc05bbd36d3ai0",
"number": 4578,
"output": "4a86d375a70a4ecc7ffcd910e05f5e0771ae6a50133543f1bf6b5651adbf0019:12",
"sat": null,
"satpoint": "4a86d375a70a4ecc7ffcd910e05f5e0771ae6a50133543f1bf6b5651adbf0019:12:0",
"timestamp": 1675607405
}
...
],
"more": true,
"page": 0
}
GET
/r/parents/<INSCRIPTION_ID>/inscriptions/<PAGE>
Description
Details of the set of 100 parent inscriptions on <PAGE>.
Exemple
curl -s -H "Accept: application/json" \
http://0.0.0.0:80/r/parents/4a86d375a70a4ecc7ffcd910e05f5e0771ae6a50133543f1bf6b5651adbf0019i0/inscriptions/1
{
"parents": [
{
"charms": [],
"fee": 65049,
"height": 775443,
"id": "972994a55c338e8458bfd156642f4aa56bdab54c68658d6b64d932fedef3c81fi0",
"number": 10804,
"output": "4a86d375a70a4ecc7ffcd910e05f5e0771ae6a50133543f1bf6b5651adbf0019:102",
"sat": null,
"satpoint": "4a86d375a70a4ecc7ffcd910e05f5e0771ae6a50133543f1bf6b5651adbf0019:102:0",
"timestamp": 1675780989
},
{
"charms": [],
"fee": 60111,
"height": 775443,
"id": "dbc21f2d3323df24a378fef3bdbe4e79c4947ce7da54968affcdefa7eda80d21i0",
"number": 10805,
"output": "4a86d375a70a4ecc7ffcd910e05f5e0771ae6a50133543f1bf6b5651adbf0019:110",
"sat": null,
"satpoint": "4a86d375a70a4ecc7ffcd910e05f5e0771ae6a50133543f1bf6b5651adbf0019:110:0",
"timestamp": 1675780989
},
{
"charms": [],
"fee": 49881,
"height": 775443,
"id": "97870f7cf65992a66d0413a7e6773190e686f185500f78c30f989f2d1f1ba922i0",
"number": 10806,
"output": "4a86d375a70a4ecc7ffcd910e05f5e0771ae6a50133543f1bf6b5651adbf0019:101",
"sat": null,
"satpoint": "4a86d375a70a4ecc7ffcd910e05f5e0771ae6a50133543f1bf6b5651adbf0019:101:0",
"timestamp": 1675780989
}
...
],
"more": false,
"page": 1
}
GET
/r/sat/<SAT_NUMBER>
Description
The first 100 inscription ids on a sat. Requires index with --index-sats
flag.
Exemple
curl -s \
http://0.0.0.0:80/r/sat/153899938226999
{
"ids": [
"f4ad941ee3892598f34777c4b7b3e2ccccece58ab21aa4364d0d2066daf5b427i3",
"a4bca99fba23122e113bfb9a8010095b2005c4d73fa5b5532de60752b768a3e5i0",
"11b4097bc9ff238c930ed4df44a6a5943ac1b570d424d7e13425244e3f345db7i0",
"488c32e4dfcdc0fa376c2c2af2d572a12f4d33d3245689d1a9f74167f1e14678i0"
],
"more": false,
"page": 0
}
GET
/r/sat/<SAT_NUMBER>/<PAGE>
Description
The set of 100 inscription ids on <PAGE>
. Requires index with --index-sats
flag.
Exemple
curl -s \
http://0.0.0.0:80/r/sat/1499676120331756/1
{
"ids": [
"c18b2db646cd23b9745bd40a249fc84975b1105a637f3784aa4dbd46a839750fi0",
"7d7c2db251779ea4147ed881daac210bfa416f39846b60e3e6813b713a393d9ai0",
"f42913d8c95f055b586fa9a6c71d2432c7ac860a9a4524c0abf83b1dbe175383i0",
"52fd615dc56a8efb241e4de141692cfa57b1af0ac5d65da7e9d5f12841c2c56ci0",
"cd65b92b9d4080a850eaf2c67c8e0c40c61ecdebeea9ae03936947f981a7b54ai0",
"708ac95fe35bcfef5403f13e5e32c927adb413ce39597abc20f8e8fa4fa1d005i0",
"2399e57a8f598b4487dda149942404e5002321139997280c736dcd0c3a806672i0",
"4a2b37c1e017646a9ba2aa13487ae55b8621972aac349426df680eaf66b90571i0",
"2a7b8b23f2a36bcff7ab23013cd13b303b8797cfac75e88d4daf1a9ddcdbdc6ai0",
"b4cac4e0c9a9ccf6428c1e3869bbbcc0e094d39d972094af21a3ca342a9afedbi0",
"c5f4bb989cc8bca10079287272d07b77b562938eaad35b3dface018cb6ac1c38i0"
],
"more": false,
"page": 1
}
GET
/r/sat/<SAT_NUMBER>/at/<INDEX>
Description
The inscription id at <INDEX>
of all inscriptions on a sat. <INDEX>
may be a negative number to index from the back. 0
being the first and -1
being the most recent for example. Requires index with --index-sats
flag.
Exemple
curl -s \
http://0.0.0.0:80/r/sat/153899938226999/at/-1
{
"id": "488c32e4dfcdc0fa376c2c2af2d572a12f4d33d3245689d1a9f74167f1e14678i0"
}
GET
/r/sat/<SAT_NUMBER>/at/<INDEX>/content
Description
The content of the inscription at <INDEX>
on a sat. <INDEX>
may be a negative number to index from the back. 0
being the first and -1
being the most recent. Requires index with --index-sats
flag.
Exemple
Fetch the content of the most recently created inscription on sat 289488340427831.
curl -s \
http://0.0.0.0:80/r/sat/289488340427831/at/-1/content
Hello, world!
GET
/r/tx/<TRANSACTION_ID>
Description
Get hex-encoded transaction with <TRANSACTION_ID>
. In the event of a future change to Bitcoin that changes transaction serialization in a backwards-incompatible fashion, such as SegWit, this endpoint is guaranteed to remain backwards compatible.
Exemple
curl -s http://0.0.0.0:80/r/tx/60bcf821240064a9c55225c4f01711b0ebbcab39aa3fafeefe4299ab158536fa
"0100000000010183572872dcb32bee57003d53c2b8dbb5bc5819ff6478052599911f7778d1c7bd0000000000fdffffff011027000000000000225120e41e0cba05c6ac797cf543ff9a6c619a91a53813e59146d1e32ea89747b111a603407aa50d93d6fc01265fd52d3edc93af4e009ccc1a704ce1b5cb8ede1412a5df31eba587d080b3dc903ceb9002ed9d921aad323fd44d7b4dc2a1ad2ea12d4360424d20c7a3a38df198a4fcde7d5dac5819ed19ff4d25bb893c9511f8e1f51d59326effac0063036f7264010118746578742f706c61696e3b636861727365743d7574662d3800077072696d65730a6821c1c7a3a38df198a4fcde7d5dac5819ed19ff4d25bb893c9511f8e1f51d59326eff00000000"
GET
/r/utxo/<OUTPOINT>
Description
Get assets held by an unspent transaction output.
Examples
Unspent transaction output with server without any indices:
curl -s \
http://0.0.0.0:80/r/utxo/4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b:0
{
"inscriptions": null,
"runes": null,
"sat_ranges": null,
"value": 5000000000
}
With rune, inscription, and sat index:
curl -s \
http://0.0.0.0:80/r/utxo/626860df36c1047194866c6812f04c15ab84f3690e7cc06fd600c841f1943e05:0
{
"inscriptions": [
"6fb976ab49dcec017f1e201e84395983204ae1a7c2abf7ced0a85d692e442799i0"
],
"runes": {
"UNCOMMON•GOODS": {
"amount": 6845,
"divisibility": 0,
"symbol": "⧉"
}
},
"sat_ranges": [
[
1905800627509113,
1905800627509443
]
],
"value": 330
}
Note: <SAT_NUMBER>
only allows the actual number of a sat no other sat notations like degree, percentile or decimal. We may expand to allow those in the future.
Responses from most of the above recursive endpoints are JSON. For backwards compatibility, some endpoints are supported which only return plain-text responses.
/blockheight
: hauteur du bloc le plus récent./blockhash
: hachage du bloc le plus récent./blockhash/<HEIGHT>
: hachage du bloc à la hauteur donnée du bloc./blocktime
: horodatage UNIX du bloc le plus récent.
See examples for on-chain examples of inscriptions that feature this functionality.
Rendering
Aspect Ratio
Inscriptions should be rendered with a square aspect ratio. Non-square aspect ratio inscriptions should not be cropped, and should instead be centered and resized to fit within their container.
Maximum Size
The ord
explorer, used by ordinals.com, displays inscription previews with a maximum size of 576 by 576 pixels, making it a reasonable choice when choosing a maximum display size.
Image Rendering
The CSS image-rendering
property controls how images are resampled when upscaled and downscaled.
When downscaling image inscriptions, image-rendering: auto
, should be used. This is desirable even when downscaling pixel art.
When upscaling image inscriptions other than AVIF, image-rendering: pixelated
should be used. This is desirable when upscaling pixel art, since it preserves the sharp edges of pixels. It is undesirable when upscaling non-pixel art, but should still be used for visual compatibility with the ord
explorer.
When upscaling AVIF and JPEG XL inscriptions, image-rendering: auto
should be used. This allows inscribers to opt-in to non-pixelated upscaling for non-pixel art inscriptions. Until such time as JPEG XL is widely supported by browsers, it is not a recommended image format.
URIs
This document is a draft. It should be considered provisional and subject to change at any time. The ord:
schema has not been registered with the IANA.
Inscriptions content can be addressed with inscription URIs using the ord:
schema.
Inscription URIs consist of ord:
followed by a target inscription ID. ord:
is not followed by //
, since the schema-specific part of inscription URIs, namely the target inscription ID, does not contain a hierarchical structure.
For example, the inscription URI of the genesis inscription is:
ord:6fb976ab49dcec017f1e201e84395983204ae1a7c2abf7ced0a85d692e442799i0
Inscription URIs match the following verbose regular expression:
(?i) # case-insensitive
ord: # schema
[0-9a-f]{64} # transaction ID
i # separator
(0|[1-9][0-9]*) # inscription index
Inscription URIs are case-insensitive and can thus use the more compact alphanumeric mode when encoded as QR codes. Lowercase is, however, the preferred presentation style.
The referent of an inscription URI is an HTTP resource with the content, content type, content encoding, and content length corresponding to the inscription with the given ID.
The referent of an inscription URI is always the original content of the target inscription, and not the content of the delegate, regardless of whether or not the target inscription has a delegate.
Inscription Examples
Delegate
- The first delegate inscription.
- The Oscillations * collection utilizes delegation, provenance, recursion, sat endpoint, and detects the kind of sat that each piece is inscribed on (sattribute-aware). Each piece is a delegate of this inscription.
- This inscription was inscribed as a delegate of this inscription and is also the parent inscription of a rune.
Métadonnées
- Each member in the FUN collection has metadata that describes its attributes.
- This inscription uses its own metadata to draw the ordinal image.
Provenance
- Inscription 0 is the parent inscription for Casey's sugar skull collection, a grandparent for the FUN! collection, and the grandparent for the sleepiest rune.
- With the Rug Me collection, owners are able to change the background color by inscribing a child to it.
- This Bitcoin Magazine Cover renders the children as part of the parent inscription.
- The yellow_ord_bot has many different quotes as cursed children.
- The Spellbound collection from the Wizard of Ord utilizes recursion, delegation, metadata, provenance, postage, location, compression.
Récursion
- Inscription 12992 was the first recursive inscription inscribed on mainnet.
- OnChain Monkey Genesis (BTC) was one of the earliest collections to use recursion to create its PFP art.
- Blob is a recursive generative collection that seeds its generation with metadata and uses threeJS, React 3 Fiber and other libraries recursively.
- The GPU Ordinals collection takes recursive content and transforms it before rendering, creating what is termed as 'super-recursion'. Use Google Chrome and headphones to experience the spatial audio.
- The Abstractii Genesis collection uses the inscriptions ID as a seed to generate its art.
- The Abstractii Evolved generative collection uses the recursive blockheight endpoint as a seed to generate its art.
- This code is called recursively in this inscription to generate music.
- This code is called recursively in this inscription, allowing it to function as a pixel art drawing program.
Runes
Runes allow Bitcoin transactions to etch, mint, and transfer Bitcoin-native digital commodities.
Whereas every inscription is unique, every unit of a rune is the same. They are interchangeable tokens, fit for a variety of purposes.
Runestones
Rune protocol messages, called runestones, are stored in Bitcoin transaction outputs.
A runestone output's script pubkey begins with an OP_RETURN
, followed by OP_13
, followed by zero or more data pushes. These data pushes are concatenated and decoded into a sequence of 128-bit integers, and finally parsed into a runestone.
A transaction may have at most one runestone.
A runestone may etch a new rune, mint an existing rune, and transfer runes from a transaction's inputs to its outputs.
A transaction output may hold balances of any number of runes.
Runes are identified by IDs, which consist of the block in which a rune was etched and the index of the etching transaction within that block, represented in text as BLOCK:TX
. For example, the ID of the rune etched in the 20th transaction of the 500th block is 500:20
.
Etching
Runes come into existence by being etched. Etching creates a rune and sets its properties. Once set, these properties are immutable, even to its etcher.
Name
Names consist of the letters A through Z and are between one and twenty-six letters long. For example UNCOMMONGOODS
is a rune name.
Names may contain spacers, represented as bullets, to aid readability. UNCOMMONGOODS
might be etched as UNCOMMON•GOODS
.
The uniqueness of a name does not depend on spacers. Thus, a rune may not be etched with the same sequence of letters as an existing rune, even if it has different spacers.
Spacers can only be placed between two letters. Finally, spacers do not count towards the letter count.
Divisibility
A rune's divisibility is how finely it may be divided into its atomic units. Divisibility is expressed as the number of digits permissible after the decimal point in an amount of runes. A rune with divisibility 0 may not be divided. A unit of a rune with divisibility 1 may be divided into ten sub-units, a rune with divisibility 2 may be divided into a hundred, and so on.
Symbol
A rune's currency symbol is a single Unicode code point, for example $
, ⧉
, or 🧿
, displayed after quantities of that rune.
101 atomic units of a rune with divisibility 2 and symbol 🧿
would be rendered as 1.01 🧿
.
If a rune does not have a symbol, the generic currency sign ¤
, also called a scarab, should be used.
Premine
The etcher of a rune may optionally allocate to themselves units of the rune being etched. This allocation is called a premine.
Terms
A rune may have an open mint, allowing anyone to create and allocate units of that rune for themselves. An open mint is subject to terms, which are set upon etching.
A mint is open while all terms of the mint are satisfied, and closed when any of them are not. For example, a mint may be limited to a starting height, an ending height, and a cap, and will be open between the starting height and ending height, or until the cap is reached, whichever comes first.
Cap
The number of times a rune may be minted is its cap. A mint is closed once the cap is reached.
Amount
Each mint transaction creates a fixed amount of new units of a rune.
Start Height
A mint is open starting in the block with the given start height.
End Height
A rune may not be minted in or after the block with the given end height.
Start Offset
A mint is open starting in the block whose height is equal to the start offset plus the height of the block in which the rune was etched.
End Offset
A rune may not be minted in or after the block whose height is equal to the end offset plus the height of the block in which the rune was etched.
Minting
While a rune's mint is open, anyone may create a mint transaction that creates a fixed amount of new units of that rune, subject to the terms of the mint.
Transferring
When transaction inputs contain runes, or new runes are created by a premine or mint, those runes are transferred to that transaction's outputs. A transaction's runestone may change how input runes transfer to outputs.
Edicts
A runestone may contain any number of edicts. Edicts consist of a rune ID, an amount, and an output number. Edicts are processed in order, allocating unallocated runes to outputs.
Pointer
After all edicts are processed, remaining unallocated runes are transferred to the transaction's first non-OP_RETURN
output. A runestone may optionally contain a pointer that specifies an alternative default output.
Burning
Runes may be burned by transferring them to an OP_RETURN
output with an edict or pointer.
Cenotaphs
Runestones may be malformed for a number of reasons, including non-pushdata opcodes in the runestone OP_RETURN
, invalid varints, or unrecognized runestone fields.
Malformed runestones are termed cenotaphs.
Runes input to a transaction with a cenotaph are burned. Runes etched in a transaction with a cenotaph are set as unmintable. Mints in a transaction with a cenotaph count towards the mint cap, but the minted runes are burned.
Cenotaphs are an upgrade mechanism, allowing runestones to be given new semantics that change how runes are created and transferred, while not misleading unupgraded clients as to the location of those runes, as unupgraded clients will see those runes as having been burned.
Runes Does Not Have a Specification
The Runes reference implementation, ord
, is the normative specification of the Runes protocol.
Nothing you read here or elsewhere, aside from the code of ord
, is a specification. This prose description of the runes protocol is provided as a guide to the behavior of ord
, and the code of ord
itself should always be consulted to confirm the correctness of any prose description.
If, due to a bug in ord
, this document diverges from the actual behavior of ord
and it is impractically disruptive to change ord
's behavior, this document will be amended to agree with ord
's actual behavior.
Users of alternative implementations do so at their own risk, and services wishing to integrate Runes are strongly encouraged to use ord
itself to make Runes transactions, and to determine the state of runes, mints, and balances.
Runestones
Rune protocol messages are termed "runestones".
The Runes protocol activates on block 840,000. Runestones in earlier blocks are ignored.
Abstractly, runestones contain the following fields:
#![allow(unused)] fn main() { struct Runestone { edicts: Vec<Edict>, etching: Option<Etching>, mint: Option<RuneId>, pointer: Option<u32>, } }
Runes are created by etchings:
#![allow(unused)] fn main() { struct Etching { divisibility: Option<u8>, premine: Option<u128>, rune: Option<Rune>, spacers: Option<u32>, symbol: Option<char>, terms: Option<Terms>, } }
Which may contain mint terms:
#![allow(unused)] fn main() { struct Terms { amount: Option<u128>, cap: Option<u128>, height: (Option<u64>, Option<u64>), offset: (Option<u64>, Option<u64>), } }
Runes are transferred by edict:
#![allow(unused)] fn main() { struct Edict { id: RuneId, amount: u128, output: u32, } }
Rune IDs are encoded as the block height and transaction index of the transaction in which the rune was etched:
#![allow(unused)] fn main() { struct RuneId { block: u64, tx: u32, } }
Rune IDs are represented in text as BLOCK:TX
.
Rune names are encoded as modified base-26 integers:
#![allow(unused)] fn main() { struct Rune(u128); }
Deciphering
Runestones are deciphered from transactions with the following steps:
-
Find the first transaction output whose script pubkey begins with
OP_RETURN OP_13
. -
Concatenate all following data pushes into a payload buffer.
-
Decode a sequence 128-bit LEB128 integers from the payload buffer.
-
Parse the sequence of integers into an untyped message.
-
Parse the untyped message into a runestone.
Deciphering may produce a malformed runestone, termed a cenotaph.
Locating the Runestone Output
Outputs are searched for the first script pubkey that beings with OP_RETURN OP_13
. If deciphering fails, later matching outputs are not considered.
Assembling the Payload Buffer
The payload buffer is assembled by concatenating data pushes, after OP_13
, in the matching script pubkey.
Data pushes are opcodes 0 through 78 inclusive. If a non-data push opcode is encountered, i.e., any opcode equal to or greater than opcode 79, the deciphered runestone is a cenotaph with no etching, mint, or edicts.
Decoding the Integer Sequence
A sequence of 128-bit integers are decoded from the payload as LEB128 varints.
LEB128 varints are encoded as sequence of bytes, each of which has the most-significant bit set, except for the last.
If a LEB128 varint contains more than 18 bytes, would overflow a u128, or is truncated, meaning that the end of the payload buffer is reached before encountering a byte with the continuation bit not set, the decoded runestone is a cenotaph with no etching, mint, or edicts.
Parsing the Message
The integer sequence is parsed into an untyped message:
#![allow(unused)] fn main() { struct Message { fields: Map<u128, Vec<u128>>, edicts: Vec<Edict>, } }
The integers are interpreted as a sequence of tag/value pairs, with duplicate tags appending their value to the field value.
If a tag with value zero is encountered, all following integers are interpreted as a series of four-integer edicts, each consisting of a rune ID block height, rune ID transaction index, amount, and output.
#![allow(unused)] fn main() { struct Edict { id: RuneId, amount: u128, output: u32, } }
Rune ID block heights and transaction indices in edicts are delta encoded.
Edict rune ID decoding starts with a base block height and transaction index of zero. When decoding each rune ID, first the encoded block height delta is added to the base block height. If the block height delta is zero, the next integer is a transaction index delta. If the block height delta is greater than zero, the next integer is instead an absolute transaction index.
This implies that edicts must first be sorted by rune ID before being encoded in a runestone.
For example, to encode the following edicts:
block | TX | amount | output |
---|---|---|---|
10 | 5 | 5 | 1 |
50 | 1 | 25 | 4 |
10 | 7 | 1 | 8 |
10 | 5 | 10 | 3 |
They are first sorted by block height and transaction index:
block | TX | amount | output |
---|---|---|---|
10 | 5 | 5 | 1 |
10 | 5 | 10 | 3 |
10 | 7 | 1 | 8 |
50 | 1 | 25 | 4 |
And then delta encoded as:
block delta | TX delta | amount | output |
---|---|---|---|
10 | 5 | 5 | 1 |
0 | 0 | 10 | 3 |
0 | 2 | 1 | 8 |
40 | 1 | 25 | 4 |
If an edict output is greater than the number of outputs of the transaction, an edict rune ID is encountered with block zero and nonzero transaction index, or a field is truncated, meaning a tag is encountered without a value, the decoded runestone is a cenotaph.
Note that if a cenotaph is produced here, the cenotaph is not empty, meaning that it contains the fields and edicts, which may include an etching and mint.
Parsing the Runestone
The runestone:
#![allow(unused)] fn main() { struct Runestone { edicts: Vec<Edict>, etching: Option<Etching>, mint: Option<RuneId>, pointer: Option<u32>, } }
Is parsed from the unsigned message using the following tags:
#![allow(unused)] fn main() { enum Tag { Body = 0, Flags = 2, Rune = 4, Premine = 6, Cap = 8, Amount = 10, HeightStart = 12, HeightEnd = 14, OffsetStart = 16, OffsetEnd = 18, Mint = 20, Pointer = 22, Cenotaph = 126, Divisibility = 1, Spacers = 3, Symbol = 5, Nop = 127, } }
Note that tags are grouped by parity, i.e., whether they are even or odd. Unrecognized odd tags are ignored. Unrecognized even tags produce a cenotaph.
All unused tags are reserved for use by the protocol, may be assigned at any time, and should not be used.
Body
The Body
tag marks the end of the runestone's fields, causing all following integers to be interpreted as edicts.
Flags
The Flag
field contains a bitmap of flags, whose position is 1 << FLAG_VALUE
:
#![allow(unused)] fn main() { enum Flag { Etching = 0, Terms = 1, Turbo = 2, Cenotaph = 127, } }
The Etching
flag marks this transaction as containing an etching.
The Terms
flag marks this transaction's etching as having open mint terms.
The Turbo
flag marks this transaction's etching as opting into future protocol changes. These protocol changes may increase light client validation costs, or just be highly degenerate.
The Cenotaph
flag is unrecognized.
If the value of the flags field after removing recognized flags is nonzero, the runestone is a cenotaph.
Rune
The Rune
field contains the name of the rune being etched. If the Etching
flag is set but the Rune
field is omitted, a reserved rune name is allocated.
Premine
The Premine
field contains the amount of premined runes.
Cap
The Cap
field contains the allowed number of mints.
Amount
The Amount
field contains the amount of runes each mint transaction receives.
HeightStart and HeightEnd
The HeightStart
and HeightEnd
fields contain the mint's starting and ending absolute block heights, respectively. The mint is open starting in the block with height HeightStart
, and closes in the block with height HeightEnd
.
OffsetStart and OffsetEnd
The OffsetStart
and OffsetEnd
fields contain the mint's starting and ending block heights, relative to the block in which the etching is mined. The mint is open starting in the block with height OffsetStart
+ ETCHING_HEIGHT
, and closes in the block with height OffsetEnd
+ ETCHING_HEIGHT
.
Mint
The Mint
field contains the Rune ID of the rune to be minted in this transaction.
Pointer
The Pointer
field contains the index of the output to which runes unallocated by edicts should be transferred. If the Pointer
field is absent, unallocated runes are transferred to the first non-OP_RETURN
output. If the pointer is greater than the number of outputs, the runestone is a cenotaph.
Cenotaph
The Cenotaph
field is unrecognized.
Divisibility
The Divisibility
field, raised to the power of ten, is the number of subunits in a super unit of runes.
For example, the amount 1234
of different runes with divisibility 0 through 3 is displayed as follows:
Divisibility | Display |
---|---|
0 | 1234 |
1 | 123.4 |
2 | 12.34 |
3 | 1.234 |
Spacers
The Spacers
field is a bitfield of •
spacers that should be displayed between the letters of the rune's name.
The Nth field of the bitfield, starting from the least significant, determines whether or not a spacer should be displayed between the Nth and N+1th character, starting from the left of the rune's name.
For example, the rune name AAAA
rendered with different spacers:
Spacers | Display |
---|---|
0b1 | A•AAA |
0b11 | A•A•AA |
0b10 | AA•AA |
0b111 | A•A•A•A |
Trailing spacers are ignored.
Symbol
The Symbol
field is the Unicode codepoint of the Rune's currency symbol, which should be displayed after amounts of that rune. If a rune does not have a currency symbol, the generic currency character ¤
should be used.
For example, if the Symbol
is #
and the divisibility is 2, the amount of 1234
units should be displayed as 12.34 #
.
Nop
The Nop
field is unrecognized.
Cenotaphs
Cenotaphs have the following effects:
-
All runes input to a transaction containing a cenotaph are burned.
-
If the runestone that produced the cenotaph contained an etching, the etched rune has supply zero and is unmintable.
-
If the runestone that produced the cenotaph is a mint, the mint counts against the mint cap and the minted runes are burned.
Cenotaphs may be created if a runestone contains an unrecognized even tag, an unrecognized flag, an edict with an output number greater than the number of inputs, a rune ID with block zero and nonzero transaction index, a malformed varint, a non-datapush instruction in the runestone output script pubkey, a tag without a following value, or trailing integers not part of an edict.
Executing the Runestone
Runestones are executed in the order their transactions are included in blocks.
Etchings
A runestone may contain an etching:
#![allow(unused)] fn main() { struct Etching { divisibility: Option<u8>, premine: Option<u128>, rune: Option<Rune>, spacers: Option<u32>, symbol: Option<char>, terms: Option<Terms>, } }
rune
is the name of the rune to be etched, encoded as modified base-26 integer.
Rune names consist of the letters A through Z, with the following encoding:
Name | Encoding |
---|---|
A | 0 |
B | 1 |
… | … |
Y | 24 |
Z | 25 |
AA | 26 |
AB | 27 |
… | … |
AY | 50 |
AZ | 51 |
BA | 52 |
And so on and so on.
Rune names AAAAAAAAAAAAAAAAAAAAAAAAAAA
and above are reserved.
If rune
is omitted a reserved rune name is allocated as follows:
#![allow(unused)] fn main() { fn reserve(block: u64, tx: u32) -> Rune { Rune( 6402364363415443603228541259936211926 + (u128::from(block) << 32 | u128::from(tx)) ) } }
6402364363415443603228541259936211926
corresponds to the rune name AAAAAAAAAAAAAAAAAAAAAAAAAAA
.
If rune
is present, it must be unlocked as of the block in which the etching appears.
Initially, all rune names of length thirteen and longer, up until the first reserved rune name, are unlocked.
Runes begin unlocking in block 840,000, the block in which the runes protocol activates.
Thereafter, every 17,500 block period, the next shortest length of rune names is continuously unlocked. So, between block 840,000 and block 857,500, the twelve-character rune names are unlocked, between block 857,500 and block 875,000 the eleven character rune names are unlocked, and so on and so on, until the one-character rune names are unlocked between block 1,032,500 and block 1,050,000. See the ord
codebase for the precise unlocking schedule.
To prevent front running an etching that has been broadcast but not mined, if a non-reserved rune name is being etched, the etching transaction must contain a valid commitment to the name being etched.
A commitment consists of a data push of the rune name, encoded as a little-endian integer with trailing zero bytes elided, present in an input witness tapscript where the output being spent has at least six confirmations.
If a valid commitment is not present, the etching is ignored.
Minting
A runestone may mint a rune by including the rune's ID in the Mint
field.
If the mint is open, the mint amount is added to the unallocated runes in the transaction's inputs. These runes may be transferred using edicts, and will otherwise be transferred to the first non-OP_RETURN
output, or the output designated by the Pointer
field.
Mints may be made in any transaction after an etching, including in the same block.
Transferring
Runes are transferred by edict:
#![allow(unused)] fn main() { struct Edict { id: RuneId, amount: u128, output: u32, } }
A runestone may contain any number of edicts, which are processed in sequence.
Before edicts are processed, input runes, as well as minted or premined runes, if any, are unallocated.
Each edict decrements the unallocated balance of rune id
and increments the balance allocated to transaction outputs of rune id
.
If an edict would allocate more runes than are currently unallocated, the amount
is reduced to the number of currently unallocated runes. In other words, the edict allocates all remaining unallocated units of rune id
.
Because the ID of an etched rune is not known before it is included in a block, ID 0:0
is used to mean the rune being etched in this transaction, if any.
An edict with amount
zero allocates all remaining units of rune id
.
An edict with output
equal to the number of transaction outputs allocates amount
runes to each non-OP_RETURN
output in order.
An edict with amount
zero and output
equal to the number of transaction outputs divides all unallocated units of rune id
between each non-OP_RETURN
output. If the number of unallocated runes is not divisible by the number of non-OP_RETURN
outputs, 1 additional rune is assigned to the first R
non-OP_RETURN
outputs, where R
is the remainder after dividing the balance of unallocated units of rune id
by the number of non-OP_RETURN
outputs.
If any edict in a runestone has a rune ID with block
zero and tx
greater than zero, or output
greater than the number of transaction outputs, the runestone is a cenotaph.
Note that edicts in cenotaphs are not processed, and all input runes are burned.
Satscard
Satscards are cards which can be used to store bitcoin, inscriptions, and runes.
Slots
Each satscard has ten slots containing private keys with corresponding bitcoin addresses.
Initially, all slots are sealed and the private keys are stored only the satscard.
Slots can be unsealed, which allows the corresponding private key to be extracted.
Unsealing is permanent. If a satscard is sealed, you can have some confidence that private key is not known to anyone. That taking physical ownership of a satscard makes you the sole owner of assets in any sealed slots.
Lifespan
Satscards are expected to have a usable lifetime of ten years. Do not use satscards for long-term storage of valuable assets.
Viewing
When placed on a smartphone, the satscard transmits a URL, beginning with https://satscard.com/start
or https://getsatscard.com/start
, depending on when it was manufactured.
This URL contains a signature which can be used to recover the address of the current slot. This signature is made over a random nonce, so it changes every time the satscard is tapped, and provides some confidence that the satscard contains the private key.
ord
supports viewing the contents of a satscard by entering the full URL into the ord
explorer search bar, or the input field on the /satscard
page.
For ordinals.com
, this is ordinals.com/satscard.
Unsealing
Satscard slots can be unsealed and the private keys extracted using the cktap
binary, available in the coinkite-tap-proto repository.
Sweeping
After a satscard slot is unsealed, all assets should be swept from that slot to another wallet, as the private key can now be read via NFC.
ord
does not yet support sweeping assets from other wallets, so assets will need to be transferred manually.
Be careful, and good luck!
FAQ de la théorie ordinale
Qu’est-ce que la théorie ordinale ?
La théorie ordinale est un protocole permettant d’attribuer des nombres de série aux satoshis, la plus petite unité de bitcoin, et de suivre ces satoshis au fur et à mesure qu’ils sont dépensés dans des transactions.
Ces numéros de série sont de grands nombres, par exemple le nombre 804766073970493. Chaque satoshi, qui est ¹⁄₁₀₀₀₀₀₀₀₀ d’un bitcoin, a un numéro ordinal.
La théorie ordinale nécessite-t-elle une chaîne latérale, un token séparé ou des modifications sur Bitcoin ?
Non ! La théorie ordinale fonctionne dès maintenant, sans chaîne latérale, et le seul token nécessaire est tout simplement le bitcoin.
À quoi sert la théorie ordinale ?
À collectionner, échanger et innover. La théorie ordinale attribue une identité aux satoshis, ce qui permet de les suivre et de les échanger, à la fois comme curiosités et pour leur valeur numismatique.
La théorie ordinale permet également les inscriptions, un protocole capable d’attacher du contenu arbitraire à des satoshis individuels, les transformant ainsi en artefacts numériques natifs de Bitcoin.
Comment fonctionne la théorie ordinale ?
Les nombres ordinaux sont attribués aux satoshis dans l’ordre dans lequel ils sont minés. Le premier satoshi du premier bloc a le nombre ordinal 0, le deuxième a le nombre ordinal 1 et le dernier satoshi du premier bloc a le nombre ordinal 4 999 999 999.
Les satoshis se trouvent dans les sorties de transactions, mais les transactions sont détruites lorsqu’elles sont émises et de nouvelles transactions sont créées. La théorie ordinale utilise donc un algorithme pour déterminer comment les satoshis se déplacent entre les sorties de transactions et les entrées de transactions.
Heureusement, cet algorithme est très simple.
Les satoshis sont transférés selon le principe FIFO (First In, First Out). Considérez les entrées d’une transaction comme une liste de satoshis, et les sorties comme une liste d’emplacements, en attente de recevoir un satoshi. Pour attribuer les satoshis des entrées aux emplacements disponibles, parcourez-les dans l’ordre et attribuez chaque satoshi au premier emplacement disponible dans les sorties.
Imaginons une transaction avec trois entrées et deux sorties. Les entrées sont à gauche de la flèche et les sorties sont à droite, avec leurs valeurs respectives :
[2] [1] [3] → [4] [2]
Voyons maintenant la même opération avec les nombres ordinaux de satoshis contenus dans chaque entrée. Nous mettrons des points d’interrogation pour chaque espace de sortie libre. Comme les nombres ordinaux sont grands, nous utiliserons des lettres pour les représenter :
[a b] [c] [d e f] → [? ? ? ?] [? ?]
Pour déterminer quel satoshi sera placé dans quelle sortie, parcourez les satoshis d’entrée dans l’ordre et attribuez un point d’interrogation à chacun d’eux :
[a b] [c] [d e f] → [a b c d] [e f]
À ce stade, vous vous demandez peut-être ce qu’il adviendra des frais... Bonne question ! Imaginons la même transaction, cette fois avec des frais de deux satoshis. Les transactions avec frais contiennent plus de satoshis dans les entrées que les sorties de transactions n’en reçoivent, donc pour convertir notre transaction en une transaction avec frais, nous allons supprimer la deuxième sortie de transaction :
[2] [1] [3] → [4]
The satoshis e and f now have nowhere to go in the outputs:
[a b] [c] [d e f] → [a b c d]
Ils vont donc au mineur qui a miné le bloc en tant que frais. Le BIP donne les détails, mais en résumé, les frais payés par les transactions sont traités comme des entrées supplémentaires dans la transaction coinbase, et sont organisés selon l’ordre de leurs transactions correspondantes dans le bloc. La transaction coinbase du bloc pourrait ressembler à ceci :
[SUBSIDY] [e f] → [SUBSIDY e f]
Où puis-je trouver les détails techniques approfondis ?
Dans le BIP !
Pourquoi les inscriptions de satoshis sont-elles appelées « artefacts numériques » au lieu de « NFTs » ?
Une inscription est un NFT, mais le terme « artefact numérique » est utilisé à la place, parce qu’il est simple, suggestif et familier.
L’expression « artefact numérique » est très suggestive, même pour quelqu’un qui n’a jamais entendu ce terme auparavant. En comparaison, le terme « NFT » est un acronyme qui ne donne aucune indication sur ce qu’il signifie si l’on n’a jamais entendu ce terme auparavant.
En outre, « NFT » ressemble à une terminologie financière, et le mot « fongible » ainsi que le sens du mot « token » tel qu’il est utilisé dans « NFT » ne sont pas courants en dehors des contextes financiers.
Comment les inscriptions de satoshis se comparent-elles…
Aux NFTs sur Ethereum ?
Les inscriptions sont toujours immuables.
Il n’y a tout simplement aucun moyen pour le créateur d’une inscription, ou le propriétaire d’une inscription, de la modifier après qu’elle a été créée.
Les NFTs sur Ethereum peuvent être immuables, mais beaucoup ne le sont pas et peuvent être modifiés ou supprimés par le propriétaire du contrat NFT.
Pour s’assurer qu’un NFT sur Ethereum est immuable, le code du contrat doit être analysé, ce qui nécessite une connaissance approfondie de l’EVM et de la sémantique Solidity.
Pour un utilisateur ne disposant pas de compétences techniques, il est assez difficile de déterminer si un NFT sur Ethereum est mutable ou immuable, et les plateformes de NFTs sur Ethereum ne font aucun effort pour distinguer si un NFT est mutable ou immuable et si le code source du contrat est disponible et a été vérifié.
Le contenu de l’inscription se trouve toujours sur la blockchain du Bitcoin.
Il est impossible pour une inscription de se référer à un contenu qui se trouve en dehors de la blockchain du Bitcoin. Cela rend les inscriptions plus durables, car le contenu ne peut pas être perdu, mais aussi plus rares, car les créateurs d’inscriptions doivent payer des commissions proportionnelles à la taille du contenu.
Le contenu de certains NFTs sur Ethereum est sur la blockchain, mais beaucoup ne l’est pas et est stocké sur des plateformes telles que IPFS ou Arweave, ou sur des serveurs web centralisés. Il n’y a aucune garantie que le contenu stocké sur IPFS continuera d’être disponible ; en fait, quelques contenus de NFTs qui étaient stockés sur IPFS ont déjà été perdus. Les plateformes telles qu’Arweave reposent sur des hypothèses économiques et sont susceptibles d’échouer de manière catastrophique lorsque ces hypothèses ne seront plus satisfaites. Les serveurs web centralisés pourraient disparaître à tout moment.
Il est très difficile pour un utilisateur non technique de déterminer où est stocké le contenu d’un NFT sur Ethereum.
Les inscriptions sont beaucoup plus simples.
Les NFTs sur Ethereum dépendent du réseau et de la machine virtuelle Ethereum, qui sont très complexes, évoluent constamment et introduisent des changements par le biais de hard forks incompatibles avec des versions précédentes.
D’autre part, les inscriptions dépendent de la blockchain du Bitcoin, qui est relativement simple et conservatrice, et qui introduit des changements par le biais de « soft forks » compatibles avec des versions précédentes.
Les inscriptions sont plus sûres.
Les inscriptions héritent du modèle de transaction de Bitcoin, ce qui permet à l’utilisateur de voir exactement quelles inscriptions sont transférées dans une transaction avant de la signer. Les inscriptions peuvent être mises en vente par le biais de transactions partiellement signées, ce qui ne nécessite pas l’autorisation d’un tiers, tel qu’une place de marché ou une plateforme d’échange, pour les transférer au nom de l’utilisateur.
En comparaison, les NFTs sur Ethereum sont criblés de vulnérabilités en matière de sécurité pour l’utilisateur final. Il est courant de signer des transactions à l’aveugle, d’accorder des autorisations illimitées à des applications tierces sur les NFTs d’un utilisateur et d’interagir avec des smart contracts complexes et imprévisibles. Cela crée un champ de mines plein de dangers pour les utilisateurs de NFTs sur Ethereum qui ne sont tout simplement pas une préoccupation pour les théoriciens d’Ordinals.
Les inscriptions sont plus rares.
Les inscriptions nécessitent des bitcoins pour être créées, transférées et stockées. Cela semble être un inconvénient à première vue, mais la raison d’être des artefacts numériques est d’être rares et donc précieux.
Les NFTs sur Ethereum, en revanche, peuvent être créés en quantités virtuellement illimitées en une seule transaction, ce qui les rend intrinsèquement moins rares, et donc potentiellement moins précieux.
Les inscriptions ne prétendent pas prendre en charge les redevances sur la blockchain.
En théorie, la mise en œuvre des redevances dans le cadre de la blockchain semble être une bonne chose, mais sa mise en pratique pose des problèmes importants. Les paiements de redevances ne peuvent pas être implémentés sur la blockchain sans restrictions complexes et intrusives. À l’heure actuelle, l’écosystème des NFTs sur Ethereum est confronté à des problèmes dus à la confusion générée autour des redevances et réalise collectivement que les redevances sur la blockchain, qui ont été présentées aux artistes comme un avantage des NFTs, ne sont pas possibles, tandis que les plateformes sont entraînées dans une course vers le bas et éliminent déjà la prise en charge des redevances.
Les inscriptions évitent totalement cette situation en ne faisant aucune fausse promesse de prise en charge des redevances sur la blockchain, évitant ainsi la confusion, le chaos et la négativité de la situation qui survient avec les NFTs sur Ethereum.
Les inscriptions ouvrent la voie à de nouveaux marchés.
La capitalisation du marché de Bitcoin et sa liquidité sont nettement supérieures à celles d’Ethereum. Une grande partie de cette liquidité n’est pas accessible aux NFTs sur Ethereum, car de nombreux bitcoiners préfèrent ne pas interagir avec l’écosystème Ethereum en raison de préoccupations liées à la simplicité, la sécurité et la décentralisation.
Ces bitcoiners pourraient être plus intéressés par les inscriptions que par les NFTs Ethereum, ce qui ouvrirait la porte à d’autres types de collectionneurs.
Les inscriptions disposent d’un modèle de données plus riche.
Une entrée se compose du type de contenu, appelé type MIME, et d’une chaîne d’octets arbitraire constituant le contenu. Il s’agit du même modèle de données que celui utilisé par le web, qui permet au contenu de l’inscription d’évoluer avec le web et de prendre en charge tout type de contenu supporté par les navigateurs web, sans qu’il soit nécessaire de modifier le protocole sous-jacent.
Aux actifs RGB et Taro ?
RGB et Taro sont tous deux des protocoles d’actifs de deuxième couche basés sur Bitcoin. Comparés aux inscriptions, ils sont beaucoup plus compliqués, mais offrent beaucoup plus de fonctionnalités.
La théorie ordinale a été conçue dès le départ pour les artefacts numériques, tandis que RGB et Taro se concentrent sur les jetons fongibles, de sorte que l’expérience utilisateur des inscriptions est susceptible d’être plus simple et plus raffinée que celle des NFTs de RGB et Taro.
RGB et Taro stockent le contenu en dehors de la blockchain, ce qui nécessite une infrastructure supplémentaire qui pourrait être perdue. En revanche, le contenu des inscriptions est stocké sur la blockchain et ne peut pas être perdu.
La théorie ordinale, RGB et Taro n’en sont qu’à leurs débuts, il ne s’agit donc que de spéculations, mais l’approche de la théorie ordinale pourrait lui donner un avantage en termes de fonctionnalité pour les artefacts numériques, notamment un meilleur modèle de contenu et des fonctionnalités telles que des symboles globalement uniques.
Aux actifs de Counterparty ?
Counterparty possède son propre token, XCP, qui est nécessaire pour certaines fonctionnalités, ce qui fait que la plupart des bitcoiners le considèrent comme un altcoin, plutôt que comme une extension ou une seconde couche de Bitcoin.
La théorie ordinale a été conçue dès le départ pour les artefacts numériques, alors que Counterparty a été principalement conçue pour l’émission de tokens financiers.
Les inscriptions pour…
Les artistes
Les inscriptions sont sur Bitcoin. Le bitcoin est la monnaie numérique la plus prestigieuse et la plus susceptible de survivre à long terme. Si vous souhaitez garantir que votre art perdure dans le futur, il n’y a pas de meilleur moyen de le publier que sous forme d’inscriptions.
Le stockage sur la blockchain est moins coûteux. Avec 20 000 dollars par BTC et des frais de transaction minimum de 1 satoshi par vbyte, publier du contenu d’inscriptions coûte 50 dollars pour 1 million d’octets.
Les inscriptions n’en sont qu’à leurs débuts ! Les inscriptions sont encore en cours de développement et n’ont pas encore été lancées sur le réseau principal. Cela vous donne l’occasion d’être un adopteur précoce et d’explorer ce medium à mesure qu’il évolue.
Les inscriptions sont simples. Il n’est pas nécessaire d’écrire ou de comprendre les smart contracts.
Les inscriptions ouvrent la porte à de nouvelles sources de liquidités. Les inscriptions sont plus accessibles et plus attrayantes pour les détenteurs de bitcoins, ce qui ouvre la porte à une toute nouvelle catégorie de collectionneurs.
Les inscriptions sont conçues pour les artefacts numériques. Les inscriptions sont conçues dès le départ pour prendre en charge les NFTs, et présentent un meilleur modèle de données, avec des caractéristiques telles que des symboles globalement uniques et une provenance améliorée.
Les inscriptions ne prennent pas en charge les redevances sur la blockchain. Cela peut être considéré comme un point négatif, mais cela dépend du point de vue de chacun. Bien que les redevances sur la blockchain aient grandement bénéficié aux créateurs, elles ont également généré une grande confusion dans l’écosystème des NFTs sur Ethereum. À l’heure actuelle, l’écosystème est aux prises avec ce problème et s’est engagé dans une course vers le bas, vers un avenir où les redevances seront facultatives. Les inscriptions ne prennent pas en charge les redevances sur la blockchain, car elles sont techniquement irréalisables. Si vous décidez de créer des inscriptions, vous pouvez contourner cette limitation de plusieurs manières : en retenant une partie de vos inscriptions pour les vendre ultérieurement, afin de bénéficier d’une appréciation future, ou en offrant peut-être des avantages aux utilisateurs qui respectent les redevances facultatives.
Les collectionneurs
Les inscriptions sont simples, claires et ne réservent aucune surprise. Elles sont toujours immuables et sur la blockchain Bitcoin, sans qu’aucune diligence particulière ne soit requise.
Les inscriptions sont sur Bitcoin. Vous pouvez facilement vérifier l’emplacement et les propriétés des inscriptions à l’aide d’un nœud complet (full node) Bitcoin que vous contrôlez.
Les bitcoiners
Permettez-moi de commencer cette section en disant que la fonction principale du réseau Bitcoin est la décentralisation de l’argent. Toutes les autres utilisations sont secondaires, y compris la théorie ordinale. Les développeurs de la théorie ordinale le comprennent très bien et considèrent que leur travail contribue, ne serait-ce qu’un peu, à la mission première de Bitcoin.
Contrairement à beaucoup d’autres choses dans l’espace altcoin, les artefacts numériques ont du mérite. Il est vrai que beaucoup de NFTs sont laids, stupides et frauduleux. Cependant, il y en a aussi beaucoup qui se distinguent par leur incroyable créativité. La création et la collection d’œuvres d’art font partie de l’histoire de l’humanité depuis ses débuts, précédant même le commerce et l’argent, qui sont également des technologies anciennes.
Bitcoin fournit une plateforme extraordinaire pour créer et collectionner des artefacts numériques de manière sécurisée et décentralisée, protégeant à la fois les utilisateurs et les artistes, et fournissant une plateforme extraordinaire pour transmettre et recevoir de la valeur.
Les ordinals et les inscriptions augmentent la demande d’espace de bloc Bitcoin, ce qui accroît le budget de sécurité de Bitcoin – ce qui est vital pour préserver la transition de Bitcoin vers un modèle de sécurité dépendant des frais, car la subvention de bloc est réduite de moitié au point de devenir insignifiante.
Le contenu des inscriptions est stocké sur la blockchain et, de ce fait, la demande d’espace de bloc pour les inscriptions est donc illimitée. Cela crée un acheteur de dernier recours pour tout l’espace de bloc Bitcoin, contribuant à soutenir un marché de frais robuste, ce qui aide à préserver la sécurité de Bitcoin.
Les inscriptions vont également à l’encontre de l’idée selon laquelle il n’est pas possible de développer ou d’utiliser Bitcoin pour de nouveaux cas d’utilisation. Si vous suivez des projets comme DLC, Fedimint, Lightning, Taro et RGB, vous savez que ce discours est faux, mais les inscriptions fournissent un contre-argument qui est facile à comprendre et qui cible un cas d’utilisation populaire et éprouvé, les NFTs, ce qui le rend très intelligible.
Si les inscriptions s’avèrent, comme l’espèrent les auteurs, être des artefacts numériques très recherchés et dotés d’une riche histoire, elles serviront d’accroche puissante pour l’adoption de Bitcoin : venez pour l’art amusant et riche, restez pour la monnaie numérique décentralisée.
Les inscriptions sont une source extrêmement bénigne de demande d’espace de bloc. Contrairement, par exemple, aux stablecoins, qui peuvent donner aux émetteurs de stablecoins une grande influence sur le développement futur de Bitcoin, ou au DeFi, qui pourrait centraliser le minage en introduisant des opportunités de MEV, il est peu probable que l’art numérique et les objets de collection sur Bitcoin produisent des entités individuelles ayant suffisamment de pouvoir pour corrompre Bitcoin. L’art est décentralisé.
Les utilisateurs et les fournisseurs de services d’inscriptions sont incités à exploiter des nœuds complets Bitcoin, à publier et à suivre les inscriptions, contribuant ainsi à renforcer la blockchain légitime grâce à leur poids économique.
La théorie ordinale et les inscriptions n’affectent pas la fongibilité de Bitcoin de manière significative. Les utilisateurs de Bitcoin peuvent ignorer les deux et ne pas être affectés.
Nous espérons que la théorie ordinale renforcera et enrichira Bitcoin, et lui donnera une autre dimension d’attrait et de fonctionnalité, lui permettant de mieux servir son cas d’utilisation principal en tant que réserve de valeur décentralisée de l’humanité.
Contribuer à ord
Étapes suggérées
- Trouvez un problème sur lequel vous voulez travailler.
- Déterminez quelle pourrait être la première mesure à prendre pour résoudre le problème. Cela pourrait se faire sous la forme d’un code, d’une recherche, d’une proposition, ou en suggérant qu’il soit clos, si le problème est obsolète ou s’il n’était pas une bonne idée dès le départ.
- Commentez le problème en décrivant les grandes lignes de la première étape que vous suggérez et demandez un retour d’information. Bien sûr, vous pourriez vous lancer immédiatement dans l’écriture du code ou de tests, mais cela vous évitera de gaspiller des efforts si le problème n’est plus d’actualité, s’il n’est pas clairement spécifié, s’il est bloqué ou s’il n’est pas prêt à être implémenté.
- Si le problème nécessite une modification du code ou la correction d’un bogue, ouvrez un brouillon de demande de tirage (pull request) avec des tests et demandez des suggestions. Cela permet de s’assurer que tout le monde est d’accord sur ce qui doit être fait, ou sur la première étape de la résolution du problème. De plus, puisque des tests sont nécessaires, le fait de les écrire en premier permet de confirmer que le changement peut être testé facilement.
- Tapez de façon aléatoire sur le clavier jusqu’à ce que les tests passent, et réusinez le code jusqu’à ce qu’il soit prêt à être soumis.
- Marquez la demande de tirage comme prête à être révisée.
- Révisez la demande de tirage si nécessaire.
- Et finalement, fusionnez-la !
Commencez modestement
Des petits changements vous permettront d’avoir un impact rapide, et si vous faites fausse route, vous n’aurez pas perdu beaucoup de temps.
Voici quelques idées pour des problèmes mineurs :
- Ajoutez un nouveau test ou un cas de test qui augmente la couverture des tests
- Ajoutez ou améliorez la documentation
- Trouvez un problème nécessitant davantage de recherche, effectuez cette recherche et résumez-la dans un commentaire
- Trouvez un problème obsolète et indiquez qu’il peut être clos dans un commentaire
- Identifiez un problème qui ne devrait pas être traité, et fournissez des commentaires constructifs expliquant pourquoi vous pensez que c’est le cas
Fusionnez tôt et souvent
Divisez les tâches importantes en plusieurs étapes plus petites, qui progressent individuellement. En cas de bogue, vous pouvez ouvrir une demande de tirage qui ajoute un test ignoré défaillant. Cela peut être fusionné, et l’étape suivante peut être de corriger le bogue et de désactiver (unignore) l’option ignorant le test. Effectuez des recherches ou des tests et faites un rapport sur vos résultats. Divisez une fonctionnalité en de petites sous-fonctionnalités et implémentez-les une par une.
Trouver un moyen de réduire la taille d’une demande de tirage volumineuse en demandes de tirages plus petites, de façon à ce que chacune puisse être fusionnée individuellement, est un art qui vaut la peine d’être pratiqué. Le défi consiste à s’assurer que chaque demande de tirage représente une amélioration en soi.
Je m’efforce de suivre ce conseil moi-même et je m’en sors toujours mieux quand je le fais.
Les petites modifications sont rapides à rédiger, à réviser et à fusionner, ce qui est beaucoup plus amusant que de travailler sur une seule demande de tirage géante qui prend une éternité à rédiger, à réviser et à fusionner. Les petites modifications ne prennent pas beaucoup de temps, donc si vous devez arrêter de travailler sur une petite modification, vous n’aurez pas perdu beaucoup de temps par rapport à une modification plus importante qui exige de nombreuses heures de travail. La soumission rapide d’une demande de tirage améliore un peu le projet, mais de façon immédiate, au lieu de devoir attendre longtemps pour obtenir une amélioration plus importante. Les petites modifications sont moins susceptibles d’entraîner des conflits de fusion. Comme le disaient les Athéniens : Les plus rapides commettent ce qu’ils veulent, tandis que les plus lents sont contraints de fusionner ce qui est possible.
Sollicitez de l’aide
Si vous êtes bloqué pendant plus de 15 minutes, demandez de l’aide dans des espaces tels que le Discord de Rust, sur Stack Exchange, ou dans le cadre d’une question ou d’une discussion au sein du projet.
Pratiquez le débogage par hypothèse
Formulez une hypothèse sur la cause du problème. Trouvez comment vérifier cette hypothèse et effectuez les tests appropriés. Si cela fonctionne, parfait, vous avez résolu le problème, ou du moins vous savez maintenant comment le faire. Dans le cas contraire, recommencez en formulant une nouvelle hypothèse.
Prêtez attention aux messages d’erreur
Lisez tous les messages d’erreur et ne tolérez pas les avertissements.
Faire un don
Ordinals est un projet open-source financé par la communauté. Le responsable actuel d’ord
est raphjaph. Le travail de Raph sur ord
est entièrement financé par des dons. Si vous le pouvez, pensez à faire un don !
L’adresse de donation pour Bitcoin est bc1q8kt9pyd6r27k2840l8g5d7zshz3cg9v6rfda0m248lva3ve5072q3sxelt. L’adresse de donation pour les inscriptions est bc1qn3map8m9hmk5jyqdkkwlwvt335g94zvxwd9aql7q3vdkdw9r5eyqvlvec0.
Les deux adresses sont dans un portefeuille multisig 2-sur-4 dont les clés sont détenues par raphjaph, erin, rodarmor, et ordinally.
Les dons reçus serviront à financer la maintenance et le développement d’ord
, ainsi que les coûts d’hébergement de ordinals.com.
Merci de faire un don !
Guides sur la théorie ordinale
Consultez la table des matières pour une liste de guides, y compris un guide de l’explorateur, un guide pour les chasseurs de sats et un guide sur les inscriptions.
JSON-API
By default, the ord server
gives access to endpoints that return JSON instead of HTML if you set the HTTP Accept: application/json
header. The structure of these objects closely follows what is shown in the HTML. These endpoints are:
Endpoints
GET
/address/<ADDRESS>
Description
List all assets of an address. Requires index with --index-addresses
flag.
Exemple
curl -s -H "Accept: application/json" \
http://0.0.0.0:80/address/bc1pdrm7tcyk4k6c3cdcjwkp49jmfrwmtvt0dvqyy7y4qp79tgks4lmqdpj6rw
{
"outputs": [
"ddf44a0e0080f458a1a1b6255a9fa0957f2611883a483c1901ccb0f59e3eb302:0",
"77c5a00da7dcf2c8f965effd25dda16ec8ec8d6b8937e89bbbdf10a1dc5aeb0d:0",
"36f5a76644ee3002483e08345feaa97a71c7a210050333a8f02e942af1294227:1434",
"e2a15acfb519ac6d95bbfd411f1f3dba4692672ea0b0a8f868da8b3f565fb428:0",
"2b84aab0b4b9869a005ae2571a94064163652f2aeffecd4fedf0397dd6b7cf41:1",
"e267548a8cc0c6e6033a6f82b355163bc1d041879206d27feb46e605b3e82759:246",
"f5b586cf0e61b7d89c18a74c47a1f8df9ff530a66ed62c02cec72fde9a23a45a:0",
"4fd271181e901809f6e2d5f89ce95ddfeb886f8db1582a35c812401af8e77661:42",
"29f8633939e956b078fb2fa0e1219089bbe2544169e7a2755e97cc254b783cb2:0",
"7aeca5c346aec84acde229e5927dd09aef680992223cfa57fe6f1ff7698b12da:0",
"cccc35d597cd5a8079f6fe54bb9c743e5297d9165b0dcfa74e74687514c66be0:0",
"590745241244d41a90df7e2cf0d7745877e4cedac573525946cc8ac7f18757e8:0",
"590745241244d41a90df7e2cf0d7745877e4cedac573525946cc8ac7f18757e8:1",
"590745241244d41a90df7e2cf0d7745877e4cedac573525946cc8ac7f18757e8:2",
"6b23a6cf6d2850f437a50f1673fc8410ae36146541b3101d8573539871a91bf0:0",
"fe130d3ca1577c65ac768f4b5b9d12a88d947ddcc31196bcf870ed5ff18403f5:2",
"5fddcbdc3eb21a93e8dd1dd3f9087c3677f422b82d5ba39a6b1ec37338154af6:0",
"c63c4910be259007e1119dbbe6fe0d923b207e78058a4f69bd54df6a3a6488f6:0"
],
"inscriptions": [
"77c5a00da7dcf2c8f965effd25dda16ec8ec8d6b8937e89bbbdf10a1dc5aeb0di0",
"1417086d6abf96f68287b799b13b0081ec895d0b4a5fb7b70d2fde404eeb8aa1i0",
"eb6636995ba074472e4193dbf65bb268ef5379509d9fffb20ddd5857039f80abi1",
"4fd271181e901809f6e2d5f89ce95ddfeb886f8db1582a35c812401af8e77661i42",
"40ab704e6123c681554102556ae3f37b0525863968311f845322fe2f2403a4c6i0",
"0b36fa5ebce6c0e028b61647a89f9488a9c9f6ad0b90a215d10eb96ee8aedf9ei0",
"87a0088e83e43a79e0e9b451037067bca726f5fd3da083e8684996dd1e6b6c70i0",
"54abce9b4380e2fe90ac0cb49b442afee76838ffd91f1ffcac46f6a6fea790c5i72",
"54abce9b4380e2fe90ac0cb49b442afee76838ffd91f1ffcac46f6a6fea790c5i768",
"b4ba20c4eb45425f4960820f493a04a3b1c2e1364927d6001e7dc7dd524cf922i931",
"781938d9e2e93698d41f30b4d1c7f7bfcd403761bce3c0ab579be47b408809e2i0",
"fe130d3ca1577c65ac768f4b5b9d12a88d947ddcc31196bcf870ed5ff18403f5i1",
"26482871f33f1051f450f2da9af275794c0b5f1c61ebf35e4467fb42c2813403i0"
],
"sat_balance": 22635,
"runes_balances": [
[
"RSIC•AUBERGINE",
"1100000000",
"🍆"
],
[
"SPACEY•CODARMOR",
"279550",
"🚀"
],
[
"ISABEL•FOXEN•DUKE",
"10000",
"⚡"
],
[
"EPIC•EPIC•EPIC•EPIC",
"1000",
"💥"
]
]
}
GET
/block/<BLOCKHASH>
Description
Returns info about the specified block.
Exemple
curl -s -H "Accept: application/json" \
http://0.0.0.0:80/block/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
{
"best_height": 864325,
"hash": "000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f",
"height": 0,
"inscriptions": [],
"runes": [],
"target": "00000000ffff0000000000000000000000000000000000000000000000000000",
"transactions": [
{
"version": 1,
"lock_time": 0,
"input": [
{
"previous_output": "0000000000000000000000000000000000000000000000000000000000000000:4294967295",
"script_sig": "04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73",
"sequence": 4294967295,
"witness": []
}
],
"output": [
{
"value": 5000000000,
"script_pubkey": "4104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac"
}
]
}
]
}
GET
/block/<BLOCKHEIGHT>
Description
Returns info about the specified block.
Exemple
curl -s -H "Accept: application/json" \
http://0.0.0.0:80/block/0
{
"best_height": 864325,
"hash": "000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f",
"height": 0,
"inscriptions": [],
"runes": [],
"target": "00000000ffff0000000000000000000000000000000000000000000000000000",
"transactions": [
{
"version": 1,
"lock_time": 0,
"input": [
{
"previous_output": "0000000000000000000000000000000000000000000000000000000000000000:4294967295",
"script_sig": "04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73",
"sequence": 4294967295,
"witness": []
}
],
"output": [
{
"value": 5000000000,
"script_pubkey": "4104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac"
}
]
}
]
}
GET
/blockcount
Description
Returns the height of the latest block.
Exemple
curl -s -H "Accept: application/json" \
http://0.0.0.0:80/blockcount
864328
GET
/blockhash
Description
Returns blockhash for the latest block.
Exemple
curl -s -H "Accept: application/json" \
http://0.0.0.0:80/blockhash
00000000000000000000c82c12a925a224605b1bb767f696ae4ff10332dbe9bc
GET
/blockhash/<BLOCKHEIGHT>
Description
Returns blockhash of specified block.
Exemple
curl -s -H "Accept: application/json" \
http://0.0.0.0:80/blockhash/840000
0000000000000000000320283a032748cef8227873ff4872689bf23f1cda83a5
GET
/blockheight
Description
Returns the height of the latest block.
Exemple
curl -s -H "Accept: application/json" \
http://0.0.0.0:80/blockheight
864330
GET
/blocks
Description
Returns the height of the latest block, the blockhashes of the last 100 blocks, and featured inscriptions from them.
Exemple
curl -s -H "Accept: application/json" \
http://0.0.0.0:80/blocks
{
"last": 864335,
"blocks": [
"00000000000000000002794398a350a04cc371ee33659296a980214f0f060adc",
"000000000000000000000470180b94350be751ea1ade67c4235c5b9515380b1f",
"000000000000000000016e1769c5aa0f3781dd99ce2d5172a696c546d442e481",
"00000000000000000002043c5ed07ad806a1c7133cf34670333326009d6195a6",
"000000000000000000017cd6200b2711c024094e64797619263d74433c2bc880",
"00000000000000000002dd6a13fffde71c09e67855d03340787e6a9b951c44df",
"00000000000000000000c82c12a925a224605b1bb767f696ae4ff10332dbe9bc",
"000000000000000000024ea66d1cddf1cfd8a3926a8e691844143da1596526db",
"00000000000000000001bd9376dfbd9689239e9c5d11d579d6c8885a0efa199c",
"0000000000000000000081f76cbccc29d92024f07f0e0b7e6b7dd063bed69bcc",
"00000000000000000000e1ca2bab230aeb6cb75b1bb5b766cb55f1a391a7d408",
"00000000000000000001fc567723ff6ccf674981202617384ae2152a711710d3",
"00000000000000000002381ab1fa4661bfecc3429424c415788cef2c62c630bb",
"000000000000000000022a1cacf15fa28d4d3698506c7b76fc62d7e50053be1f",
"000000000000000000023b6d0182255bcc633e27ecdf8a86918830fdfd4f9612",
"00000000000000000001135bd270114428c2c021e6c4161be93ba7ec9dc4e720",
"0000000000000000000269e44d995970caf720ecc272f3554d923b74c57e84ed",
"00000000000000000000e0224234536f4724c144c8da5cbaea486f3b26ef808a",
"0000000000000000000102ae83593c0b5046cc6ec3beadf133e2a9b69fb761da",
"000000000000000000014d52c9b6d9ca1fd2419562d24ff87214fcdf1688b8c4",
"00000000000000000001bc24775ec320b6af4c1210395a4092c29b7af265153c",
"00000000000000000000f4498b608a6a476bed5c4164478f618d19bcc02da3fa",
"0000000000000000000255810324c89ec4ef87a0d028968dc70aed1817bac8e8",
"0000000000000000000213bbddd4cce2831bda4865ae7025074b2a30fb228c7c",
"00000000000000000002b4cf1c7c051fd712df4447ac5e90ecde1d4429a06358",
"000000000000000000006b39a84f7bfc592293bc044c28fb57dfa660d41acc36",
"00000000000000000001cd132f83def8f13b87974eb4d2629b11f52e3016c097",
"00000000000000000001963de3de854dd9da9f384fb2ef753ba94c105cc807c6",
"00000000000000000000fc1b08733842cb0f2d3dae7f56545805b403aa0d3621",
"0000000000000000000049464eaf610aa71edaaf33e465c47981811395c3cdc7",
"0000000000000000000137881c0f7bc6b762daf8370935444fdb13b98ed4572e",
"00000000000000000001e7cc406d66013c17db6e9f8c90b807c93936fa18f192",
"0000000000000000000084d8e77f14bcdc71acedf0ba5be6b70562dcf76e2ba2",
"00000000000000000002e278d6c35e96eebb964694c430527db43301efdf367f",
"00000000000000000002ace24c94d6f927e4cad8d72839508a275d6a2882c408",
"00000000000000000002c165514bb47cef5b8eacedbabce070fc7147f6b8a48e",
"0000000000000000000251f0eabbbf2bb58837cd284a1a44275e76d11b6da62a",
"00000000000000000000650e34e08c4bc732961ce33a2b9051044ed95e95d82f",
"00000000000000000000ecd0dfe9c0a52b2a7bcf48edcdcb2df19b827afcbed2",
"0000000000000000000048131b07192e8f4466e36d025ea773e0dadcf442713f",
"000000000000000000012eb14a615f799bf628e371ee5e7dd0b518d108fc74cd",
"0000000000000000000025d47721b228c712aeb50bfd13768d8925274c1015ef",
"0000000000000000000326c89fe7dfe7737f75368ce78404c1ffb1b08c422641",
"00000000000000000002ff417f03781bbce1a1082cfaff8cf5c066c9a7547a28",
"00000000000000000002bd4acc44f416975f25aa719e07abc2c0dd12761e4d17",
"0000000000000000000188b4408d6131395ef6ca544b35cf37e7575779b15471",
"00000000000000000003253f74e3f5d35aacbef57aee3225c9e071036309aad6",
"0000000000000000000322bfda974265420bb6b604cd577410b9ca5cccbeae17",
"00000000000000000001535fdb2eb0efe673bd505bcec47a9fdedd7b83d22a6c",
"0000000000000000000169fb1a4daaaf4e08d12fcf670a81ed0f7bb4f5328494",
"0000000000000000000315eb8d0ea1cbd251c7ea2404041c352823e29a6f376a",
"000000000000000000021aef6c217e2eae81d1702d1331ab8f91360e55a60c51",
"00000000000000000000ffb1ee2423e399153433e634db68ca4aad8a829b61da",
"00000000000000000000a6e99c9e050d4345606016673d674da4aade02a8ff8a",
"00000000000000000000349de7338756bdb425cc13a3e22e986b4035d00f097b",
"00000000000000000000045218f05f939e0386ddec2460c815e5c671bfd20892",
"000000000000000000007f99d51dd0738c42ce7dc83e59061a2b33f971b6d3ab",
"00000000000000000002fc37d0f7ec804a1063a4ff8613521fcc99f1ab8fe07a",
"00000000000000000002daff4047da69c658a1badb00d14d7d3e709f76b8bf3b",
"00000000000000000001a427c71546cda9a5577d5e38bc95a5d3450df7c1d26f",
"000000000000000000004648af338d38563d26c3a5bef3ca9582ea2ccb72f8ea",
"00000000000000000001428e153a325e9aa859589a80e8b0271d1ba48e8749c7",
"000000000000000000005ea10805f8ab474b9888bdc2c2840cd2e5529bbd0d49",
"00000000000000000002c7b5bcf3372c7441e79bda1310c53f35eb59483b9092",
"00000000000000000001e2486f12c01ca0f76481b40181bf6f8f48802ade8c49",
"000000000000000000024590edc9d2d4878b32a4944dfda1a3929a6e4c9c3592",
"000000000000000000028f255235dca42b10e5da593c2d4eb006cb329a041587",
"000000000000000000006fb8f4a5d906e9c0112d5a97188f392407ab8e95bd81",
"00000000000000000002864156220f1093e76caf233009c1b6be9ee0d810ac29",
"000000000000000000009d28b5b1336abfe552aa8d92e56c1c254a1eee0e0b4b",
"000000000000000000029ad7c816c8a4f79f93e60defbc6aee7cf25e61b46008",
"00000000000000000002af0693f1c73282516b97031b7d956d07756a6f8a13d0",
"00000000000000000001376f75d1785015b1c4717b2612a7c1bc8de69817c768",
"00000000000000000000cd6e3f3ec308a26831d8866ea51beab6b02d3a5d0812",
"00000000000000000002cf32a666fabf1789ffa4fa4215f78b52406b716936d2",
"0000000000000000000310254c2c405a46c9710e52a7a7728bac5079b90e25ba",
"00000000000000000002cb11925574071edd904390823344b7ca616640971081",
"000000000000000000022e5bf2570eaee0532c0edee2a2682d4a74488ca0522f",
"000000000000000000031542e9c2b0dbd43b4e7caa3f24537af0d39bfa3997cf",
"00000000000000000002215bb1138bbc4a7611826b13e532b51d5b4e82eeac3d",
"00000000000000000001c3a1c78d27f0072f27dc1d0060273e0ef03f1bfc0ce9",
"00000000000000000001fe6ba288a1b9a14d15d3e915418cbfb54685595b0cc1",
"0000000000000000000067f8164cd2e75b3ba172cb98cd00f0894faee5c6f763",
"000000000000000000018ef9990389ca9052a0c1c93b65f780d3071346e531f3",
"000000000000000000023e7bee6b1b4647411b0279df23c9ad470d91c1b99081",
"00000000000000000000a085f77681ddf175c74b897758e9f406a17f1a278030",
"000000000000000000001bf9c32af2d6a8a4f3d50c40f927e0867d4ad9481fdd",
"00000000000000000000cde89e34036ece454ca2d07ddd7f71ab46307ca87423",
"00000000000000000001141c91e70decadd60a93f32b70b08a8ec6d74b270b08",
"000000000000000000023562ac878ab6f62329a70a15954bd56e088f3a836426",
"000000000000000000006a4455949ef37cf3c3ee6b4cc2da27137f24445c7058",
"0000000000000000000297397401eee3019168e761464c3716892951a5e33cbc",
"000000000000000000015b68955519ab2925858ebbd02f897ff81cfc4a360dd4",
"000000000000000000018a0932deb92c6bc40d46a34e654f8a2afbd6c745c6a3",
"00000000000000000001996de65cc72f1fdeaebc3141db0a2a2dd269233c8e56",
"00000000000000000000d0434cc36c19d49b9e873661ff171d632543d5c2f454",
"00000000000000000003184a301f7c76332ec629a51bcaab5652f2ba82da55d8",
"00000000000000000001e47fd13c25e24f8933b02a38c3490c0a430c0b71ea9e",
"000000000000000000027fe376111297406696afa48be122d6596b13ac15156a",
"00000000000000000002ab8ba2529a468c0f2781e3afc0f832209c94f95d4f1d"
],
"featured_blocks": {
"000000000000000000000470180b94350be751ea1ade67c4235c5b9515380b1f": [
"0ae94b05b21aa6b7f0620075db618a70124cb422fc5ced577bffbd0d103d4ce7i0",
"65f1922bc83ee43485ed884dbec24c0c1cef6c4f6d999a8ac0c09d7adc8b39dbi0",
"e87c21c7c8ba8b194bd8e389f6cb9ecb2312c076139aff31c629f93df86b98ffi0",
"aeb8d90de7e92efc11ffa6b411e829b6dcb0e00b7fd4f912947065b9084d99bai0",
"6d8f58c7f24e277d614bc6c9bb6648543e47db5431c6c073a6bd5e3be1e47c5ci0",
"770cde7a5c49ae8a4f109bd83fb364ef9b83bc6f72d3654c793f5452d7b30831i0",
"65e51357e67da9dd64a65fff1d9d26153c9969f4acfbab028e74b408559dfc07i0",
"7c63687fabdcd421de925e99b4152b2327328afe51c63903aa4a9cc9fba31872i0"
],
"000000000000000000017cd6200b2711c024094e64797619263d74433c2bc880": [
"c970b695f491a8812b5293da2673f4e6c9ae3d8be07d9da1fbb9c33a45f6fd1fi0",
"d001827b7c48e44399587f12e2fa33b2c0b1eb12c309f1c21729f1e3bc95c5fci0",
"facefc9cd6dec1cc25d7b7321cbbdaed735049a9a3da834a66975d98e23ac4dfi0",
"09353363c2e95891db553f3742a40a74c5dd1b7668669f732d58e52e7c132b92i0",
"48f3f7cbf3061957c06f66c0fe66be9ad4ad73df65b9ded1345e05f904e1e63di0",
"4e65b1d0b36c6727c646d5d6f45f00db35158a49a139282d6544f127734db9adi0",
"b8c744320e735aaaec18fd6b306d6dd678f99461e88dfa25f178627b8480e483i0",
"55d27ab1b4321addc5c34c10ef2ac4957add8b8485f465df7f2883315c9cf5f5i0"
],
"000000000000000000016e1769c5aa0f3781dd99ce2d5172a696c546d442e481": [
"cc2415293c275bea4d73ff8f45f68f269686b819de447f50ec6988ac04a62d1bi0",
"c642cd4cc7a075c61d3a32b949217990aa91dfc928f12a2cdba1f2f228c699c7i0",
"5342721d044e9e9999484b988ce9fb71097d9209c77f6549df9e31ec9b344c5bi0",
"a75f792be155a0b53691289433a6413c1efb1aeaf970f752ee70be3c6e755a06i0",
"19c0d770abaaeb5b24e718231684d53b768450cc324c8fee435910de65c459e2i0",
"30eb7c46bf4f5af33e665a119af40dd45d127cb6cdc2596de75e08f094651fa5i0",
"122631e7b8bab4238582229273a9dbe08544d2d97ad0c9a80b5829ae10ac3f27i0",
"41c304db88c60a27f45957442b857c0affefdfdca45bdf72ab4cbf9fce4d97a0i0"
],
"00000000000000000002043c5ed07ad806a1c7133cf34670333326009d6195a6": [
"2f62d6ed309f838bab143cf3a53ba758eb940b43c30c32e22d9dbf6fe7882613i0",
"83642352c5b670387874995954f79e270cb78b05a9a88b9d4d65e6f94c6df0a3i0",
"68831e3c8669ad5e8fc3585a9e8a55673123ada4c33a699e98e4d9e0297f1800i0",
"20fa9d317af18cc976a6b77797ceb5884127ac5dd7e3f131565a18dd712311c6i0",
"a286d7f705fd410cdd3f1081c4c22f196bdea4c64cfbd963f45302cdec1fe968i0",
"11eb110f86d880d8dcac852edcca7007904fda34ad031fc01f24a3e6b02ef47ci0",
"9fbec6d72d71169dc041693e740dae7bb7bb195ccd4a7f40c4c12bd4afbf7354i0",
"7c823fe74fa783debea8339fbea44b8395805295652749a651aa2133d9a1832di0"
],
"00000000000000000002794398a350a04cc371ee33659296a980214f0f060adc": [
"2596a275dca4b5cc18cd1060ab92d6df3df5507738b8f2b6b7c18c4ff1d1b36ai0",
"93256e5da147f0067d6b11e09d853b838ad1d95cf59664cccbcd52859f9ea1aci0",
"f404b5ebabd4b7fb8b88df52289b983b28f3e36fcbb63e649edea6e7ba62e582i1",
"f404b5ebabd4b7fb8b88df52289b983b28f3e36fcbb63e649edea6e7ba62e582i0",
"1bfbd226fded339cbe197153ab8b6da622c9a20e7d4911013abd385da7e05b89i0",
"af7b8810755bdf7bd62dbb6c5f2639e107a6d9d2c7199ae3650f1e7583d4bd66i0",
"9c594cb991bfecdf9d2116b644262927365f20f03ccdc8a64cbb640c11a58907i0",
"29628c91948bc100185605d11cde0aebda572d73b752bd6ed668bd86e455aa8di0"
]
}
}
GET
/blocktime
Description
Returns the UNIX timestamp of when the latest block was mined.
Exemple
curl -s -H "Accept: application/json" \
http://0.0.0.0:80/blocktime
1728158372
GET
/decode/<TRANSCATION_ID>
Description
Decode a transaction, congruent to the ord decode
command
Exemple
curl -s -H "Accept: application/json" \
http://0.0.0.0:80/decode/6fb976ab49dcec017f1e201e84395983204ae1a7c2abf7ced0a85d692e442799
{
"inscriptions": [
{
"input": 0,
"offset": 0,
"payload": {
"body": [
137,
80,
78,
71,
13,
10,
26,
10,
0,
0,
0,
13,
73,
72,
68,
82,
0,
0,
0,
100,
0,
0,
0,
100,
1,
3,
0,
0,
0,
74,
44,
7,
23,
0,
0,
0,
6,
80,
76,
84,
69,
255,
255,
255,
0,
0,
0,
85,
194,
211,
126,
0,
0,
2,
206,
73,
68,
65,
84,
56,
203,
149,
212,
75,
104,
19,
65,
24,
7,
240,
148,
74,
19,
16,
93,
20,
180,
20,
105,
22,
193,
179,
61,
21,
11,
125,
44,
228,
90,
176,
39,
41,
90,
75,
14,
30,
74,
91,
74,
43,
69,
18,
250,
200,
86,
60,
120,
80,
154,
187,
104,
5,
17,
81,
170,
205,
161,
96,
11,
77,
178,
161,
120,
145,
98,
2,
30,
4,
109,
147,
77,
201,
33,
133,
154,
221,
196,
144,
108,
146,
221,
157,
191,
33,
51,
59,
1,
193,
67,
231,
246,
227,
155,
239,
49,
51,
236,
186,
206,
184,
36,
172,
181,
209,
9,
212,
218,
18,
178,
46,
210,
214,
136,
8,
161,
189,
181,
14,
148,
179,
60,
205,
0,
108,
158,
232,
214,
36,
172,
91,
142,
196,
180,
170,
4,
100,
222,
237,
80,
85,
150,
101,
167,
140,
172,
198,
186,
21,
57,
193,
4,
77,
246,
39,
193,
138,
118,
168,
165,
198,
104,
9,
11,
172,
65,
24,
68,
7,
25,
96,
13,
194,
168,
22,
64,
134,
168,
4,
213,
172,
84,
76,
132,
152,
74,
90,
161,
170,
149,
8,
149,
247,
38,
10,
85,
104,
97,
170,
222,
95,
234,
92,
85,
157,
13,
48,
77,
162,
82,
129,
49,
206,
78,
167,
106,
149,
138,
134,
121,
58,
154,
148,
55,
235,
101,
211,
2,
83,
29,
181,
28,
202,
76,
50,
113,
141,
232,
107,
2,
232,
216,
193,
58,
146,
183,
229,
114,
142,
42,
16,
128,
49,
9,
59,
77,
53,
55,
15,
243,
26,
200,
15,
170,
25,
213,
109,
238,
89,
226,
12,
139,
69,
175,
219,
59,
197,
167,
159,
89,
222,
195,
115,
171,
198,
151,
75,
44,
47,
152,
93,
24,
54,
30,
39,
88,
77,
249,
32,
19,
215,
35,
75,
50,
213,
224,
126,
195,
171,
159,
63,
89,
166,
179,
244,
135,
177,
17,
145,
72,
63,
213,
224,
38,
89,
215,
250,
26,
123,
84,
146,
128,
245,
45,
137,
136,
84,
189,
34,
146,
154,
140,
110,
246,
40,
227,
24,
139,
251,
109,
63,
149,
32,
34,
109,
200,
240,
50,
9,
120,
45,
74,
132,
201,
189,
73,
94,
25,
125,
141,
40,
191,
121,
69,
84,
200,
16,
211,
126,
67,
194,
179,
147,
21,
166,
131,
204,
106,
119,
106,
201,
81,
118,
193,
54,
142,
19,
22,
83,
176,
211,
220,
171,
117,
30,
81,
117,
141,
8,
166,
73,
132,
231,
44,
38,
195,
232,
5,
142,
184,
170,
23,
184,
4,
25,
191,
223,
1,
25,
42,
17,
248,
185,
45,
3,
84,
18,
176,
125,
87,
129,
243,
42,
50,
201,
223,
215,
161,
210,
91,
90,
133,
153,
212,
150,
97,
80,
25,
10,
54,
116,
9,
177,
108,
75,
150,
10,
209,
47,
98,
170,
165,
142,
211,
113,
226,
247,
143,
217,
247,
138,
45,
153,
119,
106,
170,
242,
160,
50,
65,
101,
169,
127,
82,
241,
105,
76,
81,
65,
169,
78,
69,
191,
65,
161,
58,
197,
206,
98,
79,
90,
105,
180,
228,
170,
146,
239,
75,
163,
95,
231,
11,
180,
67,
125,
115,
160,
120,
156,
123,
177,
77,
21,
90,
33,
110,
75,
200,
167,
216,
107,
62,
209,
109,
131,
212,
36,
42,
9,
101,
211,
172,
59,
103,
16,
176,
146,
143,
230,
85,
194,
110,
130,
40,
205,
57,
35,
22,
85,
7,
81,
136,
142,
72,
209,
249,
252,
82,
68,
39,
139,
89,
166,
91,
1,
162,
219,
233,
53,
166,
158,
212,
225,
68,
104,
145,
193,
229,
141,
223,
120,
27,
142,
56,
186,
24,
59,
52,
3,
91,
142,
4,
25,
64,
134,
11,
0,
8,
223,
169,
120,
124,
34,
223,
233,
14,
26,
177,
220,
17,
87,
224,
101,
126,
184,
173,
57,
143,
239,
106,
91,
211,
30,
223,
229,
255,
197,
116,
143,
207,
107,
113,
205,
2,
13,
30,
235,
250,
208,
204,
251,
200,
245,
169,
153,
199,
229,
126,
228,
241,
93,
105,
87,
49,
154,
221,
121,
149,
206,
221,
230,
100,
187,
92,
104,
78,
93,
115,
212,
161,
3,
164,
232,
200,
101,
2,
102,
150,
43,
244,
230,
125,
36,
193,
37,
218,
227,
248,
231,
63,
120,
182,
245,
23,
127,
181,
197,
106,
45,
115,
252,
75,
0,
0,
0,
0,
73,
69,
78,
68,
174,
66,
96,
130
],
"content_encoding": null,
"content_type": [
105,
109,
97,
103,
101,
47,
112,
110,
103
],
"delegate": null,
"duplicate_field": false,
"incomplete_field": false,
"metadata": null,
"metaprotocol": null,
"parents": [],
"pointer": null,
"rune": null,
"unrecognized_even_field": false
},
"pushnum": false,
"stutter": false
}
],
"runestone": null
}
GET
/inscription/<INSCRIPTION_ID>
Description
Fetch details about a specific inscription by its ID.
Exemple
curl -s -H "Accept: application/json" /
http://0.0.0.0:80/inscription/6fb976ab49dcec017f1e201e84395983204ae1a7c2abf7ced0a85d692e442799i0
{
"address": "bc1ppth27qnr74qhusy9pmcyeaelgvsfky6qzquv9nf56gqmte59vfhqwkqguh",
"charms": [],
"children": [
"681b5373c03e3f819231afd9227f54101395299c9e58356bda278e2f32bef2cdi0",
"b1ef66c2d1a047cbaa6260b74daac43813924378fe08ef8545da4cb79e8fcf00i0",
"47c7260764af2ee17aa584d9c035f2e5429aefd96b8016cfe0e3f0bcf04869a3i0"
],
"content_length": 793,
"content_type": "image/png",
"effective_content_type": "image/png",
"fee": 322,
"height": 767430,
"id": "6fb976ab49dcec017f1e201e84395983204ae1a7c2abf7ced0a85d692e442799i0",
"next": "26482871f33f1051f450f2da9af275794c0b5f1c61ebf35e4467fb42c2813403i0",
"number": 0,
"parents": [],
"previous": null,
"rune": null,
"sat": null,
"satpoint": "47c7260764af2ee17aa584d9c035f2e5429aefd96b8016cfe0e3f0bcf04869a3:0:0",
"timestamp": 1671049920,
"value": 606
}
GET
/inscription/<INSCRIPTION_ID>/<CHILD>
Description
Returns the inscription information for the specified child.
Exemple
curl -s -H "Accept: application/json" \
http://0.0.0.0:80/inscription/b1ef66c2d1a047cbaa6260b74daac43813924378fe08ef8545da4cb79e8fcf00i0/0
{
"address": "bc1pnhyyzpetra3zvm376ng8ncnv9phtt45fczpt7sv2eatedtjj9vjqwhj080",
"charms": [
"vindicated"
],
"children": [],
"content_length": 106268,
"content_type": "image/avif",
"effective_content_type": "image/avif",
"fee": 1470535,
"height": 839704,
"id": "ab924ff229beca227bf40221faf492a20b5e2ee4f084524c84a5f98b80fe527fi0",
"next": "ab924ff229beca227bf40221faf492a20b5e2ee4f084524c84a5f98b80fe527fi1",
"number": 69994605,
"parents": [
"b1ef66c2d1a047cbaa6260b74daac43813924378fe08ef8545da4cb79e8fcf00i0"
],
"previous": "e2619e0fa641ed2dfba083dc57a15ca1d3f195f15d187de353e1576a0cb6e87ci8",
"rune": null,
"sat": null,
"satpoint": "ab924ff229beca227bf40221faf492a20b5e2ee4f084524c84a5f98b80fe527f:1:0",
"timestamp": 1713399652,
"value": 10000
}
POST
/inscriptions
Description
Fetch details for a list of inscription IDs.
Exemple
curl -s -X POST \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-d '["ab924ff229beca227bf40221faf492a20b5e2ee4f084524c84a5f98b80fe527fi1", "ab924ff229beca227bf40221faf492a20b5e2ee4f084524c84a5f98b80fe527fi0"]' \
http://0.0.0.0:80/inscriptions
[
{
"address": "bc1pnhyyzpetra3zvm376ng8ncnv9phtt45fczpt7sv2eatedtjj9vjqwhj080",
"charms": [
"vindicated"
],
"children": [],
"content_length": 116597,
"content_type": "image/avif",
"effective_content_type": "image/avif",
"fee": 1470535,
"height": 839704,
"id": "ab924ff229beca227bf40221faf492a20b5e2ee4f084524c84a5f98b80fe527fi1",
"next": "ab924ff229beca227bf40221faf492a20b5e2ee4f084524c84a5f98b80fe527fi2",
"number": 69994606,
"parents": [
"b1ef66c2d1a047cbaa6260b74daac43813924378fe08ef8545da4cb79e8fcf00i0"
],
"previous": "ab924ff229beca227bf40221faf492a20b5e2ee4f084524c84a5f98b80fe527fi0",
"rune": null,
"sat": null,
"satpoint": "ab924ff229beca227bf40221faf492a20b5e2ee4f084524c84a5f98b80fe527f:2:0",
"timestamp": 1713399652,
"value": 10000
},
{
"address": "bc1pnhyyzpetra3zvm376ng8ncnv9phtt45fczpt7sv2eatedtjj9vjqwhj080",
"charms": [
"vindicated"
],
"children": [],
"content_length": 106268,
"content_type": "image/avif",
"effective_content_type": "image/avif",
"fee": 1470535,
"height": 839704,
"id": "ab924ff229beca227bf40221faf492a20b5e2ee4f084524c84a5f98b80fe527fi0",
"next": "ab924ff229beca227bf40221faf492a20b5e2ee4f084524c84a5f98b80fe527fi1",
"number": 69994605,
"parents": [
"b1ef66c2d1a047cbaa6260b74daac43813924378fe08ef8545da4cb79e8fcf00i0"
],
"previous": "e2619e0fa641ed2dfba083dc57a15ca1d3f195f15d187de353e1576a0cb6e87ci8",
"rune": null,
"sat": null,
"satpoint": "ab924ff229beca227bf40221faf492a20b5e2ee4f084524c84a5f98b80fe527f:1:0",
"timestamp": 1713399652,
"value": 10000
}
]
GET
/inscriptions
Description
Get a list of the latest 100 inscriptions.
Exemple
curl -s -H "Accept: application/json" \
http://0.0.0.0:80/inscriptions
{
"ids": [
"dca3da701a2607de6c89dd0bfe6106532dcefe279d13b105301a2d85eb4ffaafi0",
"0e50a465fc0ca415f3cb8a4aac1555b12a4bf3f33bc039f2a4d39f809e83af7ai0",
"934905624f847731e7f173ba70bfa3a1389b0a7fe2a4ffce8793eef2730b9ab9i0",
"50a42e51e6ce0ef76699f017a1017d7b5b6203e67d283c625ba7d1567b2e43bai0",
"65a78bdbc1e01ac02cda181a71304a8d82305bc2a24bf01e62bea4cfff3e2dd8i0",
"05ab6d843099fb30a1da1bbfe31117cb56466b3ba40a4b3f389cc37174d339b8i0",
"47825a32dd6e3de5fd7d97488d755e6d1005e5c8552b9ede5bc67900b074d09bi0",
"737552653d4424a523f8c652710d0f9416561ea67ee25242f8606b49fb428d9ai0",
"1d7d15ab48fccf7011435584556ee9106be71f7073a857689594c143d7899333i0",
"321e4f598ae0f4841af04d1a84f3abafa44802c7d35315ead91b32ffed0f400di0",
"eb1578eaca0a04eaf174296382fc5d77530f0feceb7747938b29c433c21d1afdi0",
"70d6136e949b5f07b6ac7d50aa9aea1fa6573e1b0e4f490170235ac74738bf5ai0",
"aab2c8514876fb81cb28f0f0516620cf189222e0ffc6fe6282863bb846955409i0",
"ef36dd247b98f12d19d15bab92ea7f8491b0766fb0b8074b7606614dbbab6c13i0",
"cec42963619240ede36fb03cd95d8fba883c9c1af72b1e2fc9746151a60729dci0",
"3124d086c59ce2205f52a108e21380e2c98b1ac6a21fc2f457fb5750317997d2i0",
"c2d19ab0d9e508ed20eb6620a4ed6b5700bcee835278eb171ad15e3d9e9cf3cci0",
"6aa9e8efbc0410adebca732a2baa6812bd4d9678771023503d20c8e90f632853i0",
"96fd8d9b06c9d55d57c926889716b05f03e508d05320ffbe052aed38f49a8a4fi0",
"9429a355eecc994380920e8c9a2fd17adcb2e745bc1c8a460ed016d37e02d11ei0",
"196fa44615bd2215e17f428d9cb6ea5de62e4fc6635e45089623f757189cc3b1i0",
"077ccaf7424917873fe217bc45cfe923d20a9732373fc2b08749106569a198a8i0",
"ea5d4f47955e9ac306113ebd616587d2eaef3fb242474fb5819562ec007db32fi0",
"db377bb1c8ad40dfa6bf69b2ff8f5417b419ee6b0657e75060e088b1ec8b1c93i0",
"3c9720eeaad27cad478404905c9d5dcd332878f95dd65fc9912bfd598041af0bi0",
"61ef119d102389c3daaa5c057514f30cf1cd410b7d5c41a28c58a9a902cb265ai0",
"f971ea01b40b35b8548a902e013a3a1b799d4c2c1613d37ef3a994120d65c10ei0",
"6021306cf760dfbb0da58bce59ffbc703db5c7d9b180a3ae5268ce4c5341bf34i0",
"10aebd52ccd20124d5aa1c7d3e52fa81776ac6a3fb79ada582495328fa968ca4i0",
"9ed8d1fc12ab4d4b50c869bda1a38bb0e82b6eb18d2c14ef880aa2bb1757dbf7i0",
"5f5db3b301aa766f1a22f796248b2cceb8c111419bcefb4a3365d8bb1ff6ca05i0",
"15737d13a3583ef3559090431d5ea846e5126963046041b1f4d42b2fcc9a03eci0",
"05fdf04307e006eefec908ef93806f96c472af9e073837f4b1f5ad52e1d719a9i0",
"559280eb5ceefadee232a5b4dcc2c05dddfc1f123293482fef30ab7632855b85i0",
"76939794300cac687832e68253640e69993b46e0b75e5af4678b3c4b2037bb4bi0",
"1967e5170c27e707545ec05624db313735799fc58142e2bd2b475b088b761022i0",
"b320472502a8750fc6b3cb87ac6a0b3eaef402fa5f218f1153f658642e3d1b3di0",
"456b48e7ef556004e4a9a8b98aee8c797d75e1027dc56982ef6936f8627eeda7i0",
"02fb3081fc7317cbec7adc63761ea373ec239c7703a13f5752c3344acf6312eei0",
"75e567e30b84205ca9f5b6280b29581310bed27504949996b64858110d38c5e8i0",
"47214c34652fda5745b56ac80512e7d353db9d949fac9e0e5a6d8b27507fe4c6i0",
"c3ccc1508fb08a6bc487b25e4d5a994ff73cb44251749619c53d87c7626d74c6i0",
"a8ce87da5b67d9782846d2f718058873c51bcdbbee536540266f868bb5376c8fi0",
"47dd14ebf43bc35ff753cb5acf8335eb1acb788d05a2b0b9d83302e16170127bi0",
"ae7c0ebe825c2bf0d5820bc28da095cfa1cb6913a5913142bc327ab985b3dd7ai0",
"cf68e9b9d1967859b7d832a9c815ae3c837c94031dc8e56d848d151ae24e4776i0",
"0fe7d513cf8c19734f84321a3c49d0e0e39255702ba18546740c2bb1a95c5170i0",
"e760f5028719b2130e0d2305c3531174f4f6167282251adebfc968d127b79369i0",
"aa81f43a1412b0d04c2ef825c3829707aa32cf4cca3452077c2819f012905b5ci0",
"cd3675b40f8056c7b816c02a537a6d997912a26302f77cd3d0ad83b657d24e4bi0",
"3f8bf38d3cd3e50693b9bf187e1a374ff9990ba8e8f6337829f0d7312805741bi0",
"415a9516e1dcad84a60cc7d012c2475361d575f713b1d3aa16f982d2e43e330di0",
"6db363228406a71744cbf9b86e2b58c21b4f2dd0a0ad0affa211b32af20e8809i0",
"ff1aa5bec2a626c8b6f90e6765ceb227d44565a90f9e54cf05f5360ef6e33708i0",
"161191b5de6a1b1ed53e816545176d47e214c50711474b1a4e3ab34d70634189i0",
"f3f7488bc66000965a36f4ddf000c3d3ca3cf94d7cd4defaf3ca0b68e86b3af8i0",
"b2fb38073ade49a3f0f2522a15f4f63122a60d03a9eaed5c1c4198d339a32a1ei0",
"2f99c317739ca8cb6eb904915648ac2044f815d01ecfae6762ecf3885ee3778ai0",
"9d30636a2c5b6e064e6868fe796986014ac4cf9ea7a859d12e2dea07128c04f5i0",
"62ea57535dbe1c748d79c693e507d787af60076eaec7629365c31f52607f1279i0",
"9540b2f1d24ad5750f155ee232b03e4bfe258fde8c396844471bd595cbf0d4e9i0",
"98bfe331d267749357857e86433f974595bdb1d76ff60d35e576b217d7eae4e3i0",
"00bea5fcc8723ce5d177ca1cd4e87f7f2792fa3043231554d584b869d791a9e0i0",
"2ca9e9aedb2bf622c5c499701ce74a1dae456569082704ade20ba125019ea5f9i0",
"83290426401ac68ce29306f6a1ec5c86c69ce66049a1d85fefa49088a0f5a11fi0",
"ebc452becb7438e43281317045ab5c675376486a9344625b5dec09d5a65a9905i8",
"ebc452becb7438e43281317045ab5c675376486a9344625b5dec09d5a65a9905i7",
"ebc452becb7438e43281317045ab5c675376486a9344625b5dec09d5a65a9905i6",
"ebc452becb7438e43281317045ab5c675376486a9344625b5dec09d5a65a9905i5",
"ebc452becb7438e43281317045ab5c675376486a9344625b5dec09d5a65a9905i4",
"ebc452becb7438e43281317045ab5c675376486a9344625b5dec09d5a65a9905i3",
"ebc452becb7438e43281317045ab5c675376486a9344625b5dec09d5a65a9905i2",
"ebc452becb7438e43281317045ab5c675376486a9344625b5dec09d5a65a9905i1",
"ebc452becb7438e43281317045ab5c675376486a9344625b5dec09d5a65a9905i0",
"d431778a7290951d463f356f637a801c4c8b77767f2f53686176202bfd3a1af7i0",
"8bc9f9d88f91d851eeb84481fb33baabd6ea172c0c5152e5b8d4140f8102671ai0",
"12454b1620904b63e8c47f31e17939735515923e674fc42f299b5466258b640ai0",
"a67d21421a27918ab052c4dee3dcca86ad0610ccf4a449f98d3316008953d54ci0",
"920512aa32b5d525495832a3146f32efb0bfa308519bc3e1d5bc151ec6c9412ai0",
"8defe7abfd7d4f9dc94be83ca0b2f823f196a80ea37ebe217702368ffd2c7807i0",
"6b26e994bdabb558d41f5824b3d427ec628e7a1e7596ac20dcf05e889a994fd2i0",
"327610662171136ee252724b6860d0b64b45f81cb2bf8a0606256db730946a39i0",
"e01ec43055caa4bdb73f300076501deb85780891181d07773231db700a7d2099i0",
"9c2dc67e959bf949396d31157f16b6d60e4469ff43ba1ed44957d197f3ebf78bi0",
"89126f596c644721edc65ef293730078f16f0894baf29a1d807aab4afc013d72i0",
"3ea79b7a166ed230046e3d890d6c39a7c64dec8443de933860534449fa3180a0i0",
"2f1b248a957dcfb442b89c4684f65ba7bab7061cd0dfa4eaae8f5c65d7b41985i0",
"ac0fb3d3d301a28d3d979ca7f522eb4fdf0b0fed9d8062ff4944d5dac353092fi0",
"d0ebf39a32d409eb92bdefb354a99408367709830d03d4c6bc36786e79782720i0",
"7bfa54eb0141a93cd9cd2d3a6a52de5c1116653035bd8179608e115c823b7574i0",
"14fbc773b0b7635c4fd598c102a0a5019aee75a1184ac8d189c59478931ba6e9i0",
"0101a253d50138b4ef67c4036246df3e2a74d70874ad3c8f943af54e4b37648ci0",
"d5b41d45f3c45e2bdf36a415d9ece493cca23e762ff5de34a6abcf79936fc614i0",
"4c92503dc1f38bf77c2b1219504bb6eb82dd1d8af172f84d86d433f7bc557d4fi0",
"7b6df715cf052fdf28dbe213fada59b910c9e339137f0bd35698f23d0140a826i0",
"da06b7b4d298c837566b8daafae7cba1d4be19ca3b9e63d867cc2a9f06dd6315i0",
"958655c68793fe9e4dc6c8155c28c6b14c0ed58c5aa340d6bd6ef085134d3fb7i0",
"f8dbba73e65bf996e7cd8388ad85f7303f2caa52acf1ce793d8141dd9f70f6e6i0",
"8d166e2e3ea2a9e5d6460964d533b61656b6a3d671e5f046030319bb73f93e9fi0",
"2a60d61dff2ba192ca81614f8f0bda6c24eaac2c45f879ef84302e8c4c859bc9i2"
],
"more": true,
"page_index": 0
}
GET
/inscriptions/<PAGE>
Description
Pagination allows you to choose which page of 100 inscriptions to return.
Exemple
curl -s -H "Accept: application/json" \
http://0.0.0.0:80/inscriptions/9
{
"ids": [
"6fa8b4d1840fdd2172b51a40bde3c8b88ff2ca8b668e56fe05edb1d5eec91fc7i0",
"c6f11a3269e7ea108abb9d596c4273067f33f7e951bb4762b915a6c3c3e1ebc6i0",
"24829232f529c1c4d1bfc5c1c1410313c6388c1db14137fdc351f8659eab72c6i0",
"c068402416ec57e773d9d072ad51950b77359eddbf515a775bc6c70bf75869c6i0",
"3ffdf269a5a6a306c6e2e03b73b505a4f2dac3e0708257bca37c12d2ceec3ac6i0",
"f505cc5a01e603bee41e3986c0bfe020cd4054cbdfd0a35b57d89e375ba1e6c5i0",
"3caeb09bc1a6c7e3ac33528f69b9b10755072aac2c7b6b4f58878df45572ccc5i0",
"2233ee78d07be90ae18d12d51cc89734eb691b550b687c1547b0791de668b2c5i0",
"86475391a0e7f13f3b475e3b4aedb8ada36b63bf9bc4f9ac9203fb083a39a2c5i0",
"18fa7b8a0949b57fa4798ccf48e4ba4a16ecb14651edd5a5adc3806eaea0c9c4i0",
"fb6a338c0de40e88e03e7ae5231b036e5f452343db128b849049c2e63d0bc6c4i0",
"374e71e371dfedcfa2f9ac1d6f2d0664effe46ca27907792e396a3176a82a3c4i0",
"bc2b2fef1231c07232cd1333978366255e317e000a04c050262a7d71eaab0cc4i0",
"d627b48539c497f768279669be7690af5af8f302bfb2641989dacce8c4eed8c3i0",
"632cf2db36977e4e091ed50d61185ad78d97e7a6c6ba468b844bfd7ac9b8aec3i0",
"2fc44592a0d8924c8f48c9fcea8b189f9008f2795380446c0d13a9e452f284c3i0",
"2e84632f9f2965d8648a36e2695070e3f9a06fab1fa72176d95652a19d6d3dc3i0",
"c78e74a90bb23e55d23b221d6f184581d75f0e97acd94b6ab9c2536bae79f2c2i0",
"b4eb0dc05c24f48105d80c38c2ced8789c7910960d07db3e7326cbfae5ded9c2i0",
"5f166abe3f70f72479518451f11d67b6217a67e539c08440f844c6f71f2ea1c2i0",
"32c2d37d9bd7f6a019e48bc8bbcd0b07cee07314724f517935b1e0ff490e5cc2i0",
"0876e126bf57724045c799b0f1f6ae206d2bd15c4533212ec243951f03d834c2i0",
"6492faedbf75e28c4637b6a1e518d063c0da130c461bb193bf7215364c7bf5c1i0",
"be6f1f3e8ac1841f05dc0d67b650890dc845fbfd2d3833f48a0adb5016a6a2c1i0",
"1cb2cb5519aea30e3921d59862bb1ca7d2a61430fdf6b64dc2d84a35fcc52dc1i0",
"00d0f2dab82c0f1ba5208cd95cf204505617cdbaab854675875035f584fc0fc1i0",
"4fd6ea5ecc0660d4b238deeeef7c7a238ed324a5343e5a83d0cd34d0cba7f0c0i0",
"cb1d5b0b9c88e1cd2646939e2809119ba857770e0aacfa069ecf992745435bc0i0",
"30394ffad8c25f93083e9044b3faca9fdcce9610af522a3d72c8bf6478e612c0i0",
"2c80a5b7628e1cba9b890d4946d202fa9d534e0d4edb575ca18fc8fede1d05c0i0",
"e3bca997a4494d2c43b441eefda53ec1c63277fb79e93204787d3733bf9f91bfi0",
"7efeed6060c4a0749bd537b36d469fd874e66914b661de992a053e4702d618bfi0",
"39cc481cad92dfbe5a7db974a8f40f0b945ec0a10cf0e525a1e40214ae9b9ebei0",
"776725263fec5b995932dde0c79a511838b2f4da976d767ec357490d8e5142bei0",
"01d5456b25bf80cf0bc661f5fe65167382cb67c324ab88f9a622c0722f3934bei0",
"6cd9d02f08c818eca61fd40362855dce8157af0708460023710b2982053b2fbei0",
"ff4f062a8e1fba6d5089a7517bfadf996a24a79181cfffa479fb5142227c0bbei0",
"da23c5f3ca73c51fecdbfb7a77f028eb269bc438192e08fa7828850f7907b9bdi0",
"804a382fe000066845dd2f53bb33d880dce201b0595da73843f115d85f789dbdi0",
"3a837c80348691f965dbacf9414498c19eea184be8872509830ddc8e555611bdi0",
"d87bdf8547ff587af6ab4e9ba58cfabd81e9dbae29ebee7f91ee4ce504b1e7bci0",
"47f448eab72fa27e3ecd48cd9366f3900e13e3f385081a63027c3252452dcebci0",
"f98248bd62d1893623d07789d2b77c76c726343272fe33cffd0598496792bfbci0",
"9f4f89d78bf18eec65fad5a7e1e4b48023733678df1f831f762713aa28a7adbci0",
"99603a91e9c394b8a08e41292afa612773054a1852ad50b70b926e8ed5ff98bci0",
"ab9a8bc85f80436eb801f0b44525e735949b702b88165f276d9d5370a08792bci0",
"68a66f966af6a8df8a697d026f53ac3d1bbf16fe60e4c00046c38ca42e4c6abci0",
"f85395c84a44416973091c7b5b54093511a4e420d79b8a95f25392f60ee164bci0",
"0d94b03575c0abcd9b50463402c57c05a8fb13fdc4838b3ea38fdb4214a93fbci0",
"9101836abf01e3c2ec3b131bd392063aab15aafc15c83331e33bd5f27bddeabbi0",
"a6b1b98105d3a8b6552e191e0bc300ac432bdba02b87d7e69cca7a5f22e9cebbi0",
"38031a62f117119561f095109367359b1ec5b513cce605e99d3ad4fb3d73ccbbi0",
"518505a149382542af4a249a0ea3e8393eb11baaf1e607bb7fa089ccb0acb7bbi0",
"d6033366e191c597b5d060ccd11213625f7ca276a8dd3649db9463c401d654bbi0",
"23c94df33db29f2068237528c50bccb9af14dabeb1b4c370c1ce2cfaf2bb12bbi0",
"11407eeb6ecd4b5f721d3bdbb24d80c57bf978438466d44a37f4400dcf40dcbai0",
"26fd15fe036f3ff842e060207150594d5327963a5af729d9d7bb37f9b27cc9bai0",
"c85d49988d0a9e63b57a42b0f43b085ac848b4eec3c7567c6ff9835b28b7bfbai0",
"6f9d8c063ebd8777d42609563d5a2753739ba9822afdbd3f30248aa3622c1bbai0",
"59a5c6c8ebf33e8af27c5ca3a1fc34c6ec4a3933024431d74a7107c4cdb518bai0",
"113a792a0665cc766fe1725e94da88af51d637f0b4b2d8bab8acefc60a7fa2b9i0",
"74f75991f2f1f877c01834c8840778a67a66403ec6fe6db4889bd773a0c8f2b8i0",
"1aea70b0b26f38543f5ac323c88287b8b128f275eac1b26e316a86e14bf6c4b8i0",
"fb24445c829b8e9739be2153bf44f8962191c9ef470fa5a0a8cf6014d3939ab8i0",
"4f7bd6fb95500aad569bd9772f49545f997ffed98782938e6d030d1f0ea482b8i0",
"340716bc1585d9b57fc6c21e298caed04c84b27bd45873799b31b63d7fb965b8i0",
"cc515eb5a3125b80a8d7a2ac8e0ba54206185715332ebe6434dfbc86661053b8i0",
"e1ad8b866a5b25b67ccaf2b4e63eddb02b24e2a7abd8c3fd2c5d4ae488f83bb8i0",
"bd723e4bc055e8a43d52e80041664b94dd24a7e1a1c4aa02f39841596a0d76b7i0",
"45efc579e0fbbc539eeaf6fedc30fdd156fca6e32d7d0fff87c568b411a651b7i0",
"6ff468ac685ea84a44977322e23371aee5c6eb75d35207a60dd8b43d32632db7i0",
"9adda4d80df93b592ed215aee39da04fe4a43aec06a97f7228b483a747f4ebb6i0",
"adf97725b496134ebfd0eaaceb63f23d94052a585f557206f33443c2d659e6b6i0",
"41565db258d48adc4e0ff3467534890ee6a12beaed5378847667735affb8e2b6i0",
"fab5be5f8860e29eb394e56bd0a668752c346d1bdda73dc6a2fc2e824a17dbb6i0",
"1307d9531f2759ffcd125bdaf31ed9116c103a991a17d5b43b2e41a7e17460b6i0",
"5494d587b738c901b727c39628d94eb021a836bd78e82b20f6e331ed5c2850b6i0",
"6e98fb69311cf79bd271b13411df9e6b6138705fd08db20fe36a897eb4b513b6i0",
"f6f5d494bd9211ec6b71e9270f4a87237647e7f655ce7c10392fe1c80d8affb5i0",
"7fe37c78b2be6788af0fe810d5b6aedb1bb9c166b70667105e43de13234ee6b5i0",
"8093e0684c094a22b23f328b1dbd50c487c3ab37bc230de456a12b7fde95bcb5i0",
"7511c5ef23ab23f8e009e368b7954c4ed7e67a7a1cd94bae99b7d93a192a90b5i0",
"c98658f7731c9b5342c6a51f0860fec09fbcab9867b986d4704736abf1b0f6b4i0",
"b56001aa7fc59eb40068ea41e0f35a54f4d73c3483cd69ae0c26bb95dfc9e9b4i0",
"4147fbe40586287b1e6144c066731e43959e1aa7d3c7c8ea301ee44fd0b37fb4i0",
"3d43b7b45e4c0e062b21147be0ebdd68f9094f4e9c7b8a686aeb2948b40fbfb3i0",
"6e66c9e03e18250806515a3a60e4a6012f37e87aa1446a679ade384c7e55a3b3i0",
"8215caa5d781be0d5fae9ce7cb1a04efa17f82fb66cb2fa99e4c7bb1a2f479b3i0",
"ce288cac29042474740fa477163767a0fcf74b228e48748630ac7193118429b3i0",
"6d35d614a3574e85d80e27fdc5854a055c484dbf09f155411e279a839aa8ddb2i0",
"906804e50f92a51329b5009d65e5f6e3c32e512279c835c3171ea6765eaca6b2i0",
"70bd0c3531d62ab836187dd956e1e3fb7ef9903124b818a78e5ecd5198f5a3b2i0",
"92c2668efad88467edded7ffc50fb05a063e7b2b555ccc2073f41d599bb037b2i0",
"e97700fc461598ac01bcb2b74cde9ee31e608bfc7f53047e9e494697509f1fb2i0",
"f9d7f767ae23e67ccb9ffd21d9f83ef9a7b6617f5988a08481e1f722de05d1b1i0",
"262f07835303d1e3a8dce57c93488ed1512ad8ed633c9f129c1bc82535c99ab1i0",
"4ea5e8e9cc2c7414d2652c8db87ef556b48e61d60f68cef9c319eb87566e3db1i0",
"acfae264071fa0bb8bd7875e2d607ad48fac549c0817c2dba40858ee95571eb1i0",
"ed150d8980b923b214b8ea115a31933bbebf82666f93c68a1e11ebd3fee3d9b0i0",
"d9ea50a1c374d2feaf87a4ba82967aab419c1ecc4caac3964f69dac7323ca0b0i0"
],
"more": true,
"page_index": 9
}
GET
/inscriptions/block/<BLOCKHEIGHT>
Description
Get inscriptions for a specific block.
Exemple
curl -s -H "Accept: application/json" \
http://0.0.0.0:80/inscriptions/block/767430
{
"ids": [
"6fb976ab49dcec017f1e201e84395983204ae1a7c2abf7ced0a85d692e442799i0"
],
"more": false,
"page_index": 0
}
GET
/output/<OUTPOINT>
Description
Returns information about a UTXO, including inscriptions within it.
Exemple
curl -s -H "Accept: application/json" \
http://0.0.0.0:80/output/bc4c30829a9564c0d58e6287195622b53ced54a25711d1b86be7cd3a70ef61ed:0
{
"address": "bc1pz4kvfpurqc2hwgrq0nwtfve2lfxvdpfcdpzc6ujchyr3ztj6gd9sfr6ayf",
"indexed": false,
"inscriptions": [],
"outpoint": "bc4c30829a9564c0d58e6287195622b53ced54a25711d1b86be7cd3a70ef61ed:0",
"runes": {},
"sat_ranges": null,
"script_pubkey": "OP_PUSHNUM_1 OP_PUSHBYTES_32 156cc4878306157720607cdcb4b32afa4cc6853868458d7258b907112e5a434b",
"spent": true,
"transaction": "bc4c30829a9564c0d58e6287195622b53ced54a25711d1b86be7cd3a70ef61ed",
"value": 10000
}
POST
/outputs
Description
List information from a list of outputs.
Exemple
curl -s -X POST \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-d '["bc4c30829a9564c0d58e6287195622b53ced54a25711d1b86be7cd3a70ef61ed:0", "bc4c30829a9564c0d58e6287195622b53ced54a25711d1b86be7cd3a70ef61ed:1"]' \
http://0.0.0.0:80/outputs
[
{
"address": "bc1pz4kvfpurqc2hwgrq0nwtfve2lfxvdpfcdpzc6ujchyr3ztj6gd9sfr6ayf",
"indexed": false,
"inscriptions": [],
"outpoint": "bc4c30829a9564c0d58e6287195622b53ced54a25711d1b86be7cd3a70ef61ed:0",
"runes": {},
"sat_ranges": null,
"script_pubkey": "OP_PUSHNUM_1 OP_PUSHBYTES_32 156cc4878306157720607cdcb4b32afa4cc6853868458d7258b907112e5a434b",
"spent": true,
"transaction": "bc4c30829a9564c0d58e6287195622b53ced54a25711d1b86be7cd3a70ef61ed",
"value": 10000
},
{
"address": "bc1pkc2cdnm6xermt2vzxg9wwcur5prgpl6pms3xf9ydtyax5pnqsgwqvuu5cq",
"indexed": false,
"inscriptions": [],
"outpoint": "bc4c30829a9564c0d58e6287195622b53ced54a25711d1b86be7cd3a70ef61ed:1",
"runes": {},
"sat_ranges": null,
"script_pubkey": "5120b61586cf7a3647b5a982320ae76383a04680ff41dc2264948d593a6a0660821c",
"spent": true,
"transaction": "bc4c30829a9564c0d58e6287195622b53ced54a25711d1b86be7cd3a70ef61ed",
"value": 483528
}
]
GET
/outputs/<ADDRESS>
Description
Get UTXOs held by <ADDRESS>
.
Query Parameters
type
(optional)
Valeur | Description |
---|---|
any | return all UTXOs |
cardinal | return UTXOs not containing inscriptions or runes |
inscribed | return UTXOs containing inscriptions |
runic | return UTXOs containing runes |
Exemple
curl -s -H "Accept: application/json" \
"http://0.0.0.0:80/outputs/358mMRwcxuCSkKheuVWaXHJBGKrXo3f6JW?type=cardinal"
[
{
"address": "358mMRwcxuCSkKheuVWaXHJBGKrXo3f6JW",
"indexed": true,
"inscriptions": [],
"outpoint": "6737d77ee9fba5f37e5f4128b03479209030bf44f78ffa3f4e94bf9783691b00:0",
"runes": {},
"sat_ranges": [
[
567775159437503,
567775159443555
],
[
1266853954166100,
1266853954177531
],
[
1210436862054339,
1210436862084993
],
[
690914221328806,
690914221362332
],
[
957021421066680,
957021421075017
]
],
"script_pubkey": "a91425c70777dfcf84ba7479483e262e1bc7bb0bf4d587",
"spent": false,
"transaction": "6737d77ee9fba5f37e5f4128b03479209030bf44f78ffa3f4e94bf9783691b00",
"value": 90000
},
{
"address": "358mMRwcxuCSkKheuVWaXHJBGKrXo3f6JW",
"indexed": true,
"inscriptions": [],
"outpoint": "0cfa3e55f14812c119e47936d95abbb4e04f3094f6d86ac16c6e10018b0b2900:0",
"runes": {},
"sat_ranges": [
[
1773029001419378,
1773029001509378
]
],
"script_pubkey": "a91425c70777dfcf84ba7479483e262e1bc7bb0bf4d587",
"spent": false,
"transaction": "0cfa3e55f14812c119e47936d95abbb4e04f3094f6d86ac16c6e10018b0b2900",
"value": 90000
}
]
GET
/rune/<RUNE>
Description
Returns details about the specified rune. Requires index with --index-runes
flag.
Exemple
curl -s -H "Accept: application/json" \
http://localhost/rune/UNCOMMONGOODS
{
"entry": {
"block": 1,
"burned": 139,
"divisibility": 0,
"etching": "0000000000000000000000000000000000000000000000000000000000000000",
"mints": 33891693,
"number": 0,
"premine": 0,
"spaced_rune": "UNCOMMON•GOODS",
"symbol": "⧉",
"terms": {
"amount": 1,
"cap": 340282366920938463463374607431768211455,
"height": [
840000,
1050000
],
"offset": [
null,
null
]
},
"timestamp": 0,
"turbo": true
},
"id": "1:0",
"mintable": true,
"parent": null
}
GET
/runes
Description
Returns details for last 100 inscribed runes. Requires index with --index-runes
flag.
Exemple
curl -s -H "Accept: application/json" \
http://0.0.0.0:80/runes
{
"entries": [
[
"864348:823",
{
"block": 864348,
"burned": 0,
"divisibility": 0,
"etching": "645431123f5ff8b92d057803f2ba786689fd04f2d968d8fb6a4162b63cabc4fd",
"mints": 0,
"number": 119793,
"premine": 0,
"spaced_rune": "ZKSKOOUGYPXB",
"symbol": null,
"terms": {
"amount": 1,
"cap": 87187755,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728166072,
"turbo": false
}
],
[
"864348:822",
{
"block": 864348,
"burned": 0,
"divisibility": 0,
"etching": "9d3a1200adfcb2e0ef07e4975120980befcc265cd85b9f2300bc12d4a1ab1beb",
"mints": 0,
"number": 119792,
"premine": 0,
"spaced_rune": "VEMRWZCGQRLL",
"symbol": null,
"terms": {
"amount": 1,
"cap": 183543298,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728166072,
"turbo": false
}
],
[
"864346:427",
{
"block": 864346,
"burned": 0,
"divisibility": 0,
"etching": "2acaba44a6dc31cc5f8a8f4ee3a10eb9ca74e47d62975709cb8e81723d91a20d",
"mints": 0,
"number": 119791,
"premine": 0,
"spaced_rune": "LBQPCHACURXD",
"symbol": null,
"terms": {
"amount": 1,
"cap": 12894945,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728165011,
"turbo": false
}
],
[
"864343:2413",
{
"block": 864343,
"burned": 0,
"divisibility": 0,
"etching": "6698cd13f630107ccc4b3058cc09b1718aa435e8f9c4eba6b08eea5d13ee809b",
"mints": 0,
"number": 119790,
"premine": 1000000000,
"spaced_rune": "BABY•LEN•SASSAMAN",
"symbol": "Ⱡ",
"terms": {
"amount": 100000,
"cap": 11000,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728162943,
"turbo": false
}
],
[
"864342:2591",
{
"block": 864342,
"burned": 0,
"divisibility": 1,
"etching": "095513866c6e7aca84a39f403caac493eaa2f53eda848aaee3e96463571ec6d6",
"mints": 0,
"number": 119789,
"premine": 30000,
"spaced_rune": "COMPLETED•IT•MATE",
"symbol": "⚽",
"terms": {
"amount": 100,
"cap": 299999700,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728162376,
"turbo": true
}
],
[
"864338:4768",
{
"block": 864338,
"burned": 0,
"divisibility": 0,
"etching": "0d04505188efc69d4e2cb389607663ff556c062e1e2f8c890bfc598c637700ab",
"mints": 0,
"number": 119788,
"premine": 0,
"spaced_rune": "IJEIKMFKELRFRGRGRGEFREFGR",
"symbol": "d",
"terms": {
"amount": 211,
"cap": 554553,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728160156,
"turbo": false
}
],
[
"864338:4767",
{
"block": 864338,
"burned": 0,
"divisibility": 0,
"etching": "e0490721505254c83a69ce1411b1659b6ecd0690751cf43ac45240ca7d3ab4fb",
"mints": 0,
"number": 119787,
"premine": 0,
"spaced_rune": "CQHMUFFTWWPF",
"symbol": null,
"terms": {
"amount": 1,
"cap": 14372222,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728160156,
"turbo": false
}
],
[
"864338:4766",
{
"block": 864338,
"burned": 0,
"divisibility": 0,
"etching": "ada836a0e9c834977161543ba7bace0b552e55f88da0398626b1c49a170502dd",
"mints": 0,
"number": 119786,
"premine": 0,
"spaced_rune": "KJMKPVMKREMVBVBFBVFD",
"symbol": "3",
"terms": {
"amount": 332,
"cap": 211222,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728160156,
"turbo": false
}
],
[
"864337:4402",
{
"block": 864337,
"burned": 0,
"divisibility": 0,
"etching": "ed45aaf2e9b82d55e35a8d0654d0bb044d1d3e2fdd3eb8787d572854316c53c2",
"mints": 0,
"number": 119785,
"premine": 0,
"spaced_rune": "JNJKMLKMNJCMPMCESCVDSV•DV",
"symbol": "2",
"terms": {
"amount": 3222,
"cap": 1111111,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728160097,
"turbo": false
}
],
[
"864335:913",
{
"block": 864335,
"burned": 0,
"divisibility": 0,
"etching": "435cc412c946ced0a5ae5a50ee41d2b541f06f09b6f587619507dfbcc61b8842",
"mints": 0,
"number": 119784,
"premine": 0,
"spaced_rune": "UOBYCVAGPLNO",
"symbol": null,
"terms": {
"amount": 1,
"cap": 194090811,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728158372,
"turbo": false
}
],
[
"864335:912",
{
"block": 864335,
"burned": 0,
"divisibility": 0,
"etching": "79d77e44d66af6ec82ff7970eb3f15b9537408e3888ed0348a265810e99ddd3a",
"mints": 0,
"number": 119783,
"premine": 0,
"spaced_rune": "YNJMQPGPUGWN",
"symbol": null,
"terms": {
"amount": 1,
"cap": 71782828,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728158372,
"turbo": false
}
],
[
"864335:910",
{
"block": 864335,
"burned": 0,
"divisibility": 0,
"etching": "b014db8f651ec05a1f261f3569c66973318787ad4c7410d6677fc6fcc45e5cfe",
"mints": 0,
"number": 119782,
"premine": 0,
"spaced_rune": "FDLQGMGRYAMF",
"symbol": null,
"terms": {
"amount": 1,
"cap": 135966360,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728158372,
"turbo": false
}
],
[
"864335:909",
{
"block": 864335,
"burned": 0,
"divisibility": 0,
"etching": "bd649ba830b262ddcf24b0d6da5091f2dbf1276af26ad0809b65a95c42ddbec2",
"mints": 0,
"number": 119781,
"premine": 0,
"spaced_rune": "LBPOUDNUAIDK",
"symbol": null,
"terms": {
"amount": 1,
"cap": 128338720,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728158372,
"turbo": false
}
],
[
"864335:908",
{
"block": 864335,
"burned": 0,
"divisibility": 0,
"etching": "4ee02e12ba76c8c85208510e078810efbb3843fdaa1323d4e84f40a753d97380",
"mints": 0,
"number": 119780,
"premine": 0,
"spaced_rune": "RNVHGUYHAUCM",
"symbol": null,
"terms": {
"amount": 1,
"cap": 3346818,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728158372,
"turbo": false
}
],
[
"864335:907",
{
"block": 864335,
"burned": 0,
"divisibility": 0,
"etching": "c9b47a71a2a552450f6259262fc0c23c45148fccb52ee32cd5bb668a467a9f5d",
"mints": 0,
"number": 119779,
"premine": 0,
"spaced_rune": "RTSQQFKTEEBX",
"symbol": null,
"terms": {
"amount": 1,
"cap": 85692692,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728158372,
"turbo": false
}
],
[
"864335:906",
{
"block": 864335,
"burned": 0,
"divisibility": 0,
"etching": "df772301fef3107549d200fea54f47e46d6aae197f85e93b0068749640028055",
"mints": 0,
"number": 119778,
"premine": 0,
"spaced_rune": "IWHXSPKPYQOX",
"symbol": null,
"terms": {
"amount": 1,
"cap": 166869547,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728158372,
"turbo": false
}
],
[
"864335:905",
{
"block": 864335,
"burned": 0,
"divisibility": 0,
"etching": "186049ed6091d0a4d9e1abf6d436a6af7bc7603a33c71031b8bb0ba02f386b3a",
"mints": 0,
"number": 119777,
"premine": 0,
"spaced_rune": "OHDKZWZHYLVL",
"symbol": null,
"terms": {
"amount": 1,
"cap": 189310557,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728158372,
"turbo": false
}
],
[
"864335:904",
{
"block": 864335,
"burned": 0,
"divisibility": 0,
"etching": "74e72d9c58ce6300807d1ca6343fa95f5fa34f3d7e29fc95a94b553ff4c66b36",
"mints": 0,
"number": 119776,
"premine": 0,
"spaced_rune": "NSZNPZDDFYCT",
"symbol": null,
"terms": {
"amount": 1,
"cap": 72959668,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728158372,
"turbo": false
}
],
[
"864335:386",
{
"block": 864335,
"burned": 0,
"divisibility": 0,
"etching": "76e81c2a204074d61869f58ce86bf8ecfe66f1213bd444c4f22c6f638a401ef9",
"mints": 0,
"number": 119775,
"premine": 0,
"spaced_rune": "NTOOWMNTOOWMNTOOWM",
"symbol": null,
"terms": {
"amount": 1,
"cap": 1000000,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728158372,
"turbo": false
}
],
[
"864334:4073",
{
"block": 864334,
"burned": 0,
"divisibility": 0,
"etching": "6c132c6b69ff19d3dbbd0165bcf2fb5db9bba717824a3ff93e94e976b7da5f9e",
"mints": 0,
"number": 119774,
"premine": 0,
"spaced_rune": "HIDDEN•SELDOM•DISEASE•WISE",
"symbol": null,
"terms": {
"amount": 1,
"cap": 1127,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728158138,
"turbo": false
}
],
[
"864334:4070",
{
"block": 864334,
"burned": 0,
"divisibility": 0,
"etching": "adcbc4dc91e0b354baacb37be52e187fab2cf619c43f0675b26c5e7d58ad1ded",
"mints": 0,
"number": 119773,
"premine": 0,
"spaced_rune": "TYDSJXISYECCOQYYSS",
"symbol": null,
"terms": {
"amount": 1,
"cap": 2361833545833,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728158138,
"turbo": false
}
],
[
"864334:762",
{
"block": 864334,
"burned": 0,
"divisibility": 0,
"etching": "259fc5e99770c5d2ed0547571981ad191554282e6ab4b2a6eb4083c392edc1cb",
"mints": 0,
"number": 119772,
"premine": 0,
"spaced_rune": "BEGCOAJVXEHW",
"symbol": null,
"terms": {
"amount": 1,
"cap": 38385326,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728158138,
"turbo": false
}
],
[
"864334:433",
{
"block": 864334,
"burned": 0,
"divisibility": 0,
"etching": "4d324233f38c0cbf36bf1a76e161cbe0ff9f0efb6ee78d94dffdd5f16ec7e8ba",
"mints": 0,
"number": 119771,
"premine": 0,
"spaced_rune": "BEDIALAMDARBEDIALAMDAR",
"symbol": null,
"terms": {
"amount": 5,
"cap": 100000,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728158138,
"turbo": false
}
],
[
"864334:432",
{
"block": 864334,
"burned": 0,
"divisibility": 0,
"etching": "f7b804462b33fd468ef3b171071094f3498968b0a488d08489e16058d470d809",
"mints": 0,
"number": 119770,
"premine": 0,
"spaced_rune": "RUTHMARTINRUTHMARTIN",
"symbol": null,
"terms": {
"amount": 1,
"cap": 999999,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728158138,
"turbo": false
}
],
[
"864334:431",
{
"block": 864334,
"burned": 0,
"divisibility": 0,
"etching": "51ce542a9557a4894b0dfd705d13268682aa16c83e5eee9c5b1ba4d67113def8",
"mints": 0,
"number": 119769,
"premine": 0,
"spaced_rune": "ULTIVERSEULTIVERSE",
"symbol": null,
"terms": {
"amount": 1,
"cap": 7777777,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728158138,
"turbo": false
}
],
[
"864334:182",
{
"block": 864334,
"burned": 0,
"divisibility": 0,
"etching": "195dc952cb7c9e8a5c370fe098b4aa1d8bba8225bb4706ee7243b8e3c43f2b32",
"mints": 0,
"number": 119768,
"premine": 0,
"spaced_rune": "NUQHRKVWSYEA",
"symbol": null,
"terms": {
"amount": 1,
"cap": 3063483,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728158138,
"turbo": false
}
],
[
"864333:3461",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "65078629f16f0ce11a91da3de877a0ac5a25b5ed4c68d0ba3f6a8e75eab5f871",
"mints": 0,
"number": 119767,
"premine": 0,
"spaced_rune": "FMTJRFVGNHVZNUCB",
"symbol": null,
"terms": {
"amount": 1,
"cap": 5541274870406,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:3458",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "8471194b68cfab89a9d6112caf62f97819172d397e91674ec5413ad8f27b2828",
"mints": 0,
"number": 119766,
"premine": 0,
"spaced_rune": "WEELZZLGHGDRTO",
"symbol": null,
"terms": {
"amount": 1,
"cap": 507317119633,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:3440",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "90d530d1daf7f1f6ece388a846fe8173a427f71b7e1c5cfc1c035dcd1fc0b017",
"mints": 0,
"number": 119765,
"premine": 0,
"spaced_rune": "MIIOBBPODENFJ",
"symbol": null,
"terms": {
"amount": 1,
"cap": 503174265447,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:3437",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "5c0d2bbf9543cd50293fd6671d94502fa08c8c6d11431e0eee4ac3aedbdbc5bc",
"mints": 0,
"number": 119764,
"premine": 0,
"spaced_rune": "TASTE•RISING•FULL",
"symbol": null,
"terms": {
"amount": 1,
"cap": 4812,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:3434",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "1766810d3f53cfce81a4e0620c21e8e4643c7a40936dbafa6e88339c025fb5f6",
"mints": 0,
"number": 119763,
"premine": 0,
"spaced_rune": "REGION•MARK•LOW",
"symbol": null,
"terms": {
"amount": 1,
"cap": 2470,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:3433",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "f2a6805462cebffc6eb5855d1205dedf9c7f746a7dfd420c153011bb572f58ba",
"mints": 0,
"number": 119762,
"premine": 0,
"spaced_rune": "QHKKEWPTDMNB",
"symbol": null,
"terms": {
"amount": 1,
"cap": 53660832,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:3432",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "5d2127d84533fc9d486eaec1a2b76b2d349fe63a06a9d14847b667d360af6e19",
"mints": 0,
"number": 119761,
"premine": 0,
"spaced_rune": "IWLUKGYIWMBP",
"symbol": null,
"terms": {
"amount": 1,
"cap": 94339731,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:3431",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "ac4668d63f66c94515dbc2a74faa9152018758a75432cc085a7e7638a24cbc12",
"mints": 0,
"number": 119760,
"premine": 0,
"spaced_rune": "KWUFVEOJVKGQ",
"symbol": null,
"terms": {
"amount": 1,
"cap": 196312580,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:2714",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "c642cd4cc7a075c61d3a32b949217990aa91dfc928f12a2cdba1f2f228c699c7",
"mints": 26,
"number": 119759,
"premine": 210000,
"spaced_rune": "BOUNCE•THE•BITCOIN•CAT",
"symbol": "🐱",
"terms": {
"amount": 1000,
"cap": 20790,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": true
}
],
[
"864333:2482",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "cc2415293c275bea4d73ff8f45f68f269686b819de447f50ec6988ac04a62d1b",
"mints": 0,
"number": 119758,
"premine": 30000000,
"spaced_rune": "BITCAT•IS•IN•CONTROL",
"symbol": "🐈",
"terms": {
"amount": 5000,
"cap": 194000,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": true
}
],
[
"864333:2462",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "a75f792be155a0b53691289433a6413c1efb1aeaf970f752ee70be3c6e755a06",
"mints": 0,
"number": 119757,
"premine": 0,
"spaced_rune": "FIRST•CAT•EATING•BITCOINER",
"symbol": "🙀",
"terms": {
"amount": 1000,
"cap": 21000,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": true
}
],
[
"864333:1142",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "7488c2909e2bb5f39fb836ee1e18c23487d078e48e2420cc11776c8d7931fea5",
"mints": 0,
"number": 119756,
"premine": 0,
"spaced_rune": "AI•CRYPTO•AI•CRYPTO",
"symbol": "A",
"terms": {
"amount": 1000,
"cap": 1,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:1140",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "a024e2d4c4e15eab941376a954bb9176bc95990ba6b2a6d31e5b7c26cd8d7e7c",
"mints": 0,
"number": 119755,
"premine": 0,
"spaced_rune": "SACMKSOKCMPOKMWCLWMCLWCDWC",
"symbol": "c",
"terms": {
"amount": 221,
"cap": 2111111,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:1136",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "d6358e0601130c5ebbdb535aa93bbe2e752fd7fd6eee8601fe5af29e7ff179e1",
"mints": 0,
"number": 119754,
"premine": 0,
"spaced_rune": "XQOFVAHHLCQR",
"symbol": null,
"terms": {
"amount": 1,
"cap": 94964916,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:1135",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "62aa2bd48b0eb8a1c3bb090c6129bdc52a2348f3b8e25a2e2eeaa27313e242af",
"mints": 0,
"number": 119753,
"premine": 0,
"spaced_rune": "YEPWCVNODTII",
"symbol": null,
"terms": {
"amount": 1,
"cap": 39185064,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:1134",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "e3e6a144d3ac57d35f7f141f79ea818bd26a78bf900c2d0aeaa2a95ce68f8c9e",
"mints": 0,
"number": 119752,
"premine": 0,
"spaced_rune": "SDFGJUJTYHTGRSFAD",
"symbol": null,
"terms": {
"amount": 1,
"cap": 5,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:1133",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "97600a89179c0bfd4b7c69bc5f4e9fc2f206124fbc08d4872f18ac6be29a525e",
"mints": 0,
"number": 119751,
"premine": 0,
"spaced_rune": "XQEKAAGEYDXY",
"symbol": null,
"terms": {
"amount": 1,
"cap": 147617461,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:1131",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "8ecabca3a2b1518c67c5ee41c93e7874d1117edfd0b36e46ea68eb83e6f9eaad",
"mints": 0,
"number": 119750,
"premine": 0,
"spaced_rune": "XFHSGMZJEUML",
"symbol": null,
"terms": {
"amount": 1,
"cap": 1014672,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:1130",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "77b1518d7ad77d89118eeb8eb92c120e1732d2e7ce9d6780cda180f5f4968df6",
"mints": 0,
"number": 119749,
"premine": 0,
"spaced_rune": "DJLNUHRYYTGR",
"symbol": null,
"terms": {
"amount": 1,
"cap": 146717679,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:1129",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "4da09c158447950fabd281c7910c6e3f251b9b9a98ab7058e2f4b26304e332ee",
"mints": 0,
"number": 119748,
"premine": 0,
"spaced_rune": "CBAQVALKVMYP",
"symbol": null,
"terms": {
"amount": 1,
"cap": 181932658,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:1128",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "b947075130f5a5f93a5cdfa9a216c76b761ff7cd2fb7ca677b3d00a3ca5d53e0",
"mints": 0,
"number": 119747,
"premine": 0,
"spaced_rune": "POJSRGWQBBWQ",
"symbol": null,
"terms": {
"amount": 1,
"cap": 100105873,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:1127",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "a356dd06600bb163cb4d68bbe601f83d987c3c2cd456e3784616ab297d1843c0",
"mints": 0,
"number": 119746,
"premine": 0,
"spaced_rune": "FMPQPSLKENKY",
"symbol": null,
"terms": {
"amount": 1,
"cap": 82531312,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:1126",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "b6ecdb27bb269949f58ace2ba162726483070e80c140dc60329b5fdbbd3e6395",
"mints": 0,
"number": 119745,
"premine": 0,
"spaced_rune": "GOARBTCEASGJ",
"symbol": null,
"terms": {
"amount": 1,
"cap": 99967467,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:1125",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "abf680ed211d18428ddda208f164539fbf662705bd88d4041575c53e655ed794",
"mints": 0,
"number": 119744,
"premine": 0,
"spaced_rune": "MNBIUEEAKPBJ",
"symbol": null,
"terms": {
"amount": 1,
"cap": 168164931,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:1124",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "74e290bc2ed6b39c887ab3b456f86d91edbadb829936c63bb166d42233527491",
"mints": 0,
"number": 119743,
"burned": 0,
"divisibility": 0,
"etching": "74e290bc2ed6b39c887ab3b456f86d91edbadb829936c63bb166d42233527491",
"mints": 0,
"number": 119743,
"divisibility": 0,
"etching": "74e290bc2ed6b39c887ab3b456f86d91edbadb829936c63bb166d42233527491",
"mints": 0,
"number": 119743,
"premine": 0,
"spaced_rune": "CWTYCFSOTBSU",
"symbol": null,
"etching": "74e290bc2ed6b39c887ab3b456f86d91edbadb829936c63bb166d42233527491",
"mints": 0,
"number": 119743,
"premine": 0,
"spaced_rune": "CWTYCFSOTBSU",
"symbol": null,
"terms": {
"amount": 1,
"cap": 29807122,
"mints": 0,
"number": 119743,
"premine": 0,
"spaced_rune": "CWTYCFSOTBSU",
"symbol": null,
"terms": {
"amount": 1,
"cap": 29807122,
"premine": 0,
"spaced_rune": "CWTYCFSOTBSU",
"symbol": null,
"terms": {
"amount": 1,
"cap": 29807122,
"height": [
null,
null
"terms": {
"amount": 1,
"cap": 29807122,
"height": [
null,
null
"height": [
null,
null
null
],
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
]
],
"more": true,
"prev": null,
"next": 1
}
GET
/runes/<PAGE>
Description
Pagination allows you to specify which page of 100 runes you'd like to return.
Exemple
curl -s -H "Accept: application/json" \
http://0.0.0.0:80/runes/0
{
"entries": [
[
"864348:823",
{
"block": 864348,
"burned": 0,
"divisibility": 0,
"etching": "645431123f5ff8b92d057803f2ba786689fd04f2d968d8fb6a4162b63cabc4fd",
"mints": 0,
"number": 119793,
"premine": 0,
"spaced_rune": "ZKSKOOUGYPXB",
"symbol": null,
"terms": {
"amount": 1,
"cap": 87187755,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728166072,
"turbo": false
}
],
[
"864348:822",
{
"block": 864348,
"burned": 0,
"divisibility": 0,
"etching": "9d3a1200adfcb2e0ef07e4975120980befcc265cd85b9f2300bc12d4a1ab1beb",
"mints": 0,
"number": 119792,
"premine": 0,
"spaced_rune": "VEMRWZCGQRLL",
"symbol": null,
"terms": {
"amount": 1,
"cap": 183543298,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728166072,
"turbo": false
}
],
[
"864346:427",
{
"block": 864346,
"burned": 0,
"divisibility": 0,
"etching": "2acaba44a6dc31cc5f8a8f4ee3a10eb9ca74e47d62975709cb8e81723d91a20d",
"mints": 0,
"number": 119791,
"premine": 0,
"spaced_rune": "LBQPCHACURXD",
"symbol": null,
"terms": {
"amount": 1,
"cap": 12894945,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728165011,
"turbo": false
}
],
[
"864343:2413",
{
"block": 864343,
"burned": 0,
"divisibility": 0,
"etching": "6698cd13f630107ccc4b3058cc09b1718aa435e8f9c4eba6b08eea5d13ee809b",
"mints": 0,
"number": 119790,
"premine": 1000000000,
"spaced_rune": "BABY•LEN•SASSAMAN",
"symbol": "Ⱡ",
"terms": {
"amount": 100000,
"cap": 11000,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728162943,
"turbo": false
}
],
[
"864342:2591",
{
"block": 864342,
"burned": 0,
"divisibility": 1,
"etching": "095513866c6e7aca84a39f403caac493eaa2f53eda848aaee3e96463571ec6d6",
"mints": 0,
"number": 119789,
"premine": 30000,
"spaced_rune": "COMPLETED•IT•MATE",
"symbol": "⚽",
"terms": {
"amount": 100,
"cap": 299999700,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728162376,
"turbo": true
}
],
[
"864338:4768",
{
"block": 864338,
"burned": 0,
"divisibility": 0,
"etching": "0d04505188efc69d4e2cb389607663ff556c062e1e2f8c890bfc598c637700ab",
"mints": 0,
"number": 119788,
"premine": 0,
"spaced_rune": "IJEIKMFKELRFRGRGRGEFREFGR",
"symbol": "d",
"terms": {
"amount": 211,
"cap": 554553,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728160156,
"turbo": false
}
],
[
"864338:4767",
{
"block": 864338,
"burned": 0,
"divisibility": 0,
"etching": "e0490721505254c83a69ce1411b1659b6ecd0690751cf43ac45240ca7d3ab4fb",
"mints": 0,
"number": 119787,
"premine": 0,
"spaced_rune": "CQHMUFFTWWPF",
"symbol": null,
"terms": {
"amount": 1,
"cap": 14372222,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728160156,
"turbo": false
}
],
[
"864338:4766",
{
"block": 864338,
"burned": 0,
"divisibility": 0,
"etching": "ada836a0e9c834977161543ba7bace0b552e55f88da0398626b1c49a170502dd",
"mints": 0,
"number": 119786,
"premine": 0,
"spaced_rune": "KJMKPVMKREMVBVBFBVFD",
"symbol": "3",
"terms": {
"amount": 332,
"cap": 211222,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728160156,
"turbo": false
}
],
[
"864337:4402",
{
"block": 864337,
"burned": 0,
"divisibility": 0,
"etching": "ed45aaf2e9b82d55e35a8d0654d0bb044d1d3e2fdd3eb8787d572854316c53c2",
"mints": 0,
"number": 119785,
"premine": 0,
"spaced_rune": "JNJKMLKMNJCMPMCESCVDSV•DV",
"symbol": "2",
"terms": {
"amount": 3222,
"cap": 1111111,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728160097,
"turbo": false
}
],
[
"864335:913",
{
"block": 864335,
"burned": 0,
"divisibility": 0,
"etching": "435cc412c946ced0a5ae5a50ee41d2b541f06f09b6f587619507dfbcc61b8842",
"mints": 0,
"number": 119784,
"premine": 0,
"spaced_rune": "UOBYCVAGPLNO",
"symbol": null,
"terms": {
"amount": 1,
"cap": 194090811,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728158372,
"turbo": false
}
],
[
"864335:912",
{
"block": 864335,
"burned": 0,
"divisibility": 0,
"etching": "79d77e44d66af6ec82ff7970eb3f15b9537408e3888ed0348a265810e99ddd3a",
"mints": 0,
"number": 119783,
"premine": 0,
"spaced_rune": "YNJMQPGPUGWN",
"symbol": null,
"terms": {
"amount": 1,
"cap": 71782828,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728158372,
"turbo": false
}
],
[
"864335:910",
{
"block": 864335,
"burned": 0,
"divisibility": 0,
"etching": "b014db8f651ec05a1f261f3569c66973318787ad4c7410d6677fc6fcc45e5cfe",
"mints": 0,
"number": 119782,
"premine": 0,
"spaced_rune": "FDLQGMGRYAMF",
"symbol": null,
"terms": {
"amount": 1,
"cap": 135966360,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728158372,
"turbo": false
}
],
[
"864335:909",
{
"block": 864335,
"burned": 0,
"divisibility": 0,
"etching": "bd649ba830b262ddcf24b0d6da5091f2dbf1276af26ad0809b65a95c42ddbec2",
"mints": 0,
"number": 119781,
"premine": 0,
"spaced_rune": "LBPOUDNUAIDK",
"symbol": null,
"terms": {
"amount": 1,
"cap": 128338720,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728158372,
"turbo": false
}
],
[
"864335:908",
{
"block": 864335,
"burned": 0,
"divisibility": 0,
"etching": "4ee02e12ba76c8c85208510e078810efbb3843fdaa1323d4e84f40a753d97380",
"mints": 0,
"number": 119780,
"premine": 0,
"spaced_rune": "RNVHGUYHAUCM",
"symbol": null,
"terms": {
"amount": 1,
"cap": 3346818,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728158372,
"turbo": false
}
],
[
"864335:907",
{
"block": 864335,
"burned": 0,
"divisibility": 0,
"etching": "c9b47a71a2a552450f6259262fc0c23c45148fccb52ee32cd5bb668a467a9f5d",
"mints": 0,
"number": 119779,
"premine": 0,
"spaced_rune": "RTSQQFKTEEBX",
"symbol": null,
"terms": {
"amount": 1,
"cap": 85692692,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728158372,
"turbo": false
}
],
[
"864335:906",
{
"block": 864335,
"burned": 0,
"divisibility": 0,
"etching": "df772301fef3107549d200fea54f47e46d6aae197f85e93b0068749640028055",
"mints": 0,
"number": 119778,
"premine": 0,
"spaced_rune": "IWHXSPKPYQOX",
"symbol": null,
"terms": {
"amount": 1,
"cap": 166869547,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728158372,
"turbo": false
}
],
[
"864335:905",
{
"block": 864335,
"burned": 0,
"divisibility": 0,
"etching": "186049ed6091d0a4d9e1abf6d436a6af7bc7603a33c71031b8bb0ba02f386b3a",
"mints": 0,
"number": 119777,
"premine": 0,
"spaced_rune": "OHDKZWZHYLVL",
"symbol": null,
"terms": {
"amount": 1,
"cap": 189310557,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728158372,
"turbo": false
}
],
[
"864335:904",
{
"block": 864335,
"burned": 0,
"divisibility": 0,
"etching": "74e72d9c58ce6300807d1ca6343fa95f5fa34f3d7e29fc95a94b553ff4c66b36",
"mints": 0,
"number": 119776,
"premine": 0,
"spaced_rune": "NSZNPZDDFYCT",
"symbol": null,
"terms": {
"amount": 1,
"cap": 72959668,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728158372,
"turbo": false
}
],
[
"864335:386",
{
"block": 864335,
"burned": 0,
"divisibility": 0,
"etching": "76e81c2a204074d61869f58ce86bf8ecfe66f1213bd444c4f22c6f638a401ef9",
"mints": 0,
"number": 119775,
"premine": 0,
"spaced_rune": "NTOOWMNTOOWMNTOOWM",
"symbol": null,
"terms": {
"amount": 1,
"cap": 1000000,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728158372,
"turbo": false
}
],
[
"864334:4073",
{
"block": 864334,
"burned": 0,
"divisibility": 0,
"etching": "6c132c6b69ff19d3dbbd0165bcf2fb5db9bba717824a3ff93e94e976b7da5f9e",
"mints": 0,
"number": 119774,
"premine": 0,
"spaced_rune": "HIDDEN•SELDOM•DISEASE•WISE",
"symbol": null,
"terms": {
"amount": 1,
"cap": 1127,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728158138,
"turbo": false
}
],
[
"864334:4070",
{
"block": 864334,
"burned": 0,
"divisibility": 0,
"etching": "adcbc4dc91e0b354baacb37be52e187fab2cf619c43f0675b26c5e7d58ad1ded",
"mints": 0,
"number": 119773,
"premine": 0,
"spaced_rune": "TYDSJXISYECCOQYYSS",
"symbol": null,
"terms": {
"amount": 1,
"cap": 2361833545833,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728158138,
"turbo": false
}
],
[
"864334:762",
{
"block": 864334,
"burned": 0,
"divisibility": 0,
"etching": "259fc5e99770c5d2ed0547571981ad191554282e6ab4b2a6eb4083c392edc1cb",
"mints": 0,
"number": 119772,
"premine": 0,
"spaced_rune": "BEGCOAJVXEHW",
"symbol": null,
"terms": {
"amount": 1,
"cap": 38385326,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728158138,
"turbo": false
}
],
[
"864334:433",
{
"block": 864334,
"burned": 0,
"divisibility": 0,
"etching": "4d324233f38c0cbf36bf1a76e161cbe0ff9f0efb6ee78d94dffdd5f16ec7e8ba",
"mints": 0,
"number": 119771,
"premine": 0,
"spaced_rune": "BEDIALAMDARBEDIALAMDAR",
"symbol": null,
"terms": {
"amount": 5,
"cap": 100000,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728158138,
"turbo": false
}
],
[
"864334:432",
{
"block": 864334,
"burned": 0,
"divisibility": 0,
"etching": "f7b804462b33fd468ef3b171071094f3498968b0a488d08489e16058d470d809",
"mints": 0,
"number": 119770,
"premine": 0,
"spaced_rune": "RUTHMARTINRUTHMARTIN",
"symbol": null,
"terms": {
"amount": 1,
"cap": 999999,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728158138,
"turbo": false
}
],
[
"864334:431",
{
"block": 864334,
"burned": 0,
"divisibility": 0,
"etching": "51ce542a9557a4894b0dfd705d13268682aa16c83e5eee9c5b1ba4d67113def8",
"mints": 0,
"number": 119769,
"premine": 0,
"spaced_rune": "ULTIVERSEULTIVERSE",
"symbol": null,
"terms": {
"amount": 1,
"cap": 7777777,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728158138,
"turbo": false
}
],
[
"864334:182",
{
"block": 864334,
"burned": 0,
"divisibility": 0,
"etching": "195dc952cb7c9e8a5c370fe098b4aa1d8bba8225bb4706ee7243b8e3c43f2b32",
"mints": 0,
"number": 119768,
"premine": 0,
"spaced_rune": "NUQHRKVWSYEA",
"symbol": null,
"terms": {
"amount": 1,
"cap": 3063483,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728158138,
"turbo": false
}
],
[
"864333:3461",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "65078629f16f0ce11a91da3de877a0ac5a25b5ed4c68d0ba3f6a8e75eab5f871",
"mints": 0,
"number": 119767,
"premine": 0,
"spaced_rune": "FMTJRFVGNHVZNUCB",
"symbol": null,
"terms": {
"amount": 1,
"cap": 5541274870406,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:3458",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "8471194b68cfab89a9d6112caf62f97819172d397e91674ec5413ad8f27b2828",
"mints": 0,
"number": 119766,
"premine": 0,
"spaced_rune": "WEELZZLGHGDRTO",
"symbol": null,
"terms": {
"amount": 1,
"cap": 507317119633,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:3440",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "90d530d1daf7f1f6ece388a846fe8173a427f71b7e1c5cfc1c035dcd1fc0b017",
"mints": 0,
"number": 119765,
"premine": 0,
"spaced_rune": "MIIOBBPODENFJ",
"symbol": null,
"terms": {
"amount": 1,
"cap": 503174265447,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:3437",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "5c0d2bbf9543cd50293fd6671d94502fa08c8c6d11431e0eee4ac3aedbdbc5bc",
"mints": 0,
"number": 119764,
"premine": 0,
"spaced_rune": "TASTE•RISING•FULL",
"symbol": null,
"terms": {
"amount": 1,
"cap": 4812,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:3434",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "1766810d3f53cfce81a4e0620c21e8e4643c7a40936dbafa6e88339c025fb5f6",
"mints": 0,
"number": 119763,
"premine": 0,
"spaced_rune": "REGION•MARK•LOW",
"symbol": null,
"terms": {
"amount": 1,
"cap": 2470,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:3433",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "f2a6805462cebffc6eb5855d1205dedf9c7f746a7dfd420c153011bb572f58ba",
"mints": 0,
"number": 119762,
"premine": 0,
"spaced_rune": "QHKKEWPTDMNB",
"symbol": null,
"terms": {
"amount": 1,
"cap": 53660832,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:3432",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "5d2127d84533fc9d486eaec1a2b76b2d349fe63a06a9d14847b667d360af6e19",
"mints": 0,
"number": 119761,
"premine": 0,
"spaced_rune": "IWLUKGYIWMBP",
"symbol": null,
"terms": {
"amount": 1,
"cap": 94339731,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:3431",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "ac4668d63f66c94515dbc2a74faa9152018758a75432cc085a7e7638a24cbc12",
"mints": 0,
"number": 119760,
"premine": 0,
"spaced_rune": "KWUFVEOJVKGQ",
"symbol": null,
"terms": {
"amount": 1,
"cap": 196312580,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:2714",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "c642cd4cc7a075c61d3a32b949217990aa91dfc928f12a2cdba1f2f228c699c7",
"mints": 26,
"number": 119759,
"premine": 210000,
"spaced_rune": "BOUNCE•THE•BITCOIN•CAT",
"symbol": "🐱",
"terms": {
"amount": 1000,
"cap": 20790,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": true
}
],
[
"864333:2482",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "cc2415293c275bea4d73ff8f45f68f269686b819de447f50ec6988ac04a62d1b",
"mints": 0,
"number": 119758,
"premine": 30000000,
"spaced_rune": "BITCAT•IS•IN•CONTROL",
"symbol": "🐈",
"terms": {
"amount": 5000,
"cap": 194000,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": true
}
],
[
"864333:2462",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "a75f792be155a0b53691289433a6413c1efb1aeaf970f752ee70be3c6e755a06",
"mints": 0,
"number": 119757,
"premine": 0,
"spaced_rune": "FIRST•CAT•EATING•BITCOINER",
"symbol": "🙀",
"terms": {
"amount": 1000,
"cap": 21000,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": true
}
],
[
"864333:1142",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "7488c2909e2bb5f39fb836ee1e18c23487d078e48e2420cc11776c8d7931fea5",
"mints": 0,
"number": 119756,
"premine": 0,
"spaced_rune": "AI•CRYPTO•AI•CRYPTO",
"symbol": "A",
"terms": {
"amount": 1000,
"cap": 1,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:1140",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "a024e2d4c4e15eab941376a954bb9176bc95990ba6b2a6d31e5b7c26cd8d7e7c",
"mints": 0,
"number": 119755,
"premine": 0,
"spaced_rune": "SACMKSOKCMPOKMWCLWMCLWCDWC",
"symbol": "c",
"terms": {
"amount": 221,
"cap": 2111111,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:1136",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "d6358e0601130c5ebbdb535aa93bbe2e752fd7fd6eee8601fe5af29e7ff179e1",
"mints": 0,
"number": 119754,
"premine": 0,
"spaced_rune": "XQOFVAHHLCQR",
"symbol": null,
"terms": {
"amount": 1,
"cap": 94964916,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:1135",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "62aa2bd48b0eb8a1c3bb090c6129bdc52a2348f3b8e25a2e2eeaa27313e242af",
"mints": 0,
"number": 119753,
"premine": 0,
"spaced_rune": "YEPWCVNODTII",
"symbol": null,
"terms": {
"amount": 1,
"cap": 39185064,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:1134",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "e3e6a144d3ac57d35f7f141f79ea818bd26a78bf900c2d0aeaa2a95ce68f8c9e",
"mints": 0,
"number": 119752,
"premine": 0,
"spaced_rune": "SDFGJUJTYHTGRSFAD",
"symbol": null,
"terms": {
"amount": 1,
"cap": 5,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:1133",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "97600a89179c0bfd4b7c69bc5f4e9fc2f206124fbc08d4872f18ac6be29a525e",
"mints": 0,
"number": 119751,
"premine": 0,
"spaced_rune": "XQEKAAGEYDXY",
"symbol": null,
"terms": {
"amount": 1,
"cap": 147617461,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:1131",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "8ecabca3a2b1518c67c5ee41c93e7874d1117edfd0b36e46ea68eb83e6f9eaad",
"mints": 0,
"number": 119750,
"premine": 0,
"spaced_rune": "XFHSGMZJEUML",
"symbol": null,
"terms": {
"amount": 1,
"cap": 1014672,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:1130",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "77b1518d7ad77d89118eeb8eb92c120e1732d2e7ce9d6780cda180f5f4968df6",
"mints": 0,
"number": 119749,
"premine": 0,
"spaced_rune": "DJLNUHRYYTGR",
"symbol": null,
"terms": {
"amount": 1,
"cap": 146717679,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:1129",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "4da09c158447950fabd281c7910c6e3f251b9b9a98ab7058e2f4b26304e332ee",
"mints": 0,
"number": 119748,
"premine": 0,
"spaced_rune": "CBAQVALKVMYP",
"symbol": null,
"terms": {
"amount": 1,
"cap": 181932658,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:1128",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "b947075130f5a5f93a5cdfa9a216c76b761ff7cd2fb7ca677b3d00a3ca5d53e0",
"mints": 0,
"number": 119747,
"premine": 0,
"spaced_rune": "POJSRGWQBBWQ",
"symbol": null,
"terms": {
"amount": 1,
"cap": 100105873,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:1127",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "a356dd06600bb163cb4d68bbe601f83d987c3c2cd456e3784616ab297d1843c0",
"mints": 0,
"number": 119746,
"premine": 0,
"spaced_rune": "FMPQPSLKENKY",
"symbol": null,
"terms": {
"amount": 1,
"cap": 82531312,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:1126",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "b6ecdb27bb269949f58ace2ba162726483070e80c140dc60329b5fdbbd3e6395",
"mints": 0,
"number": 119745,
"premine": 0,
"spaced_rune": "GOARBTCEASGJ",
"symbol": null,
"terms": {
"amount": 1,
"cap": 99967467,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:1125",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "abf680ed211d18428ddda208f164539fbf662705bd88d4041575c53e655ed794",
"mints": 0,
"number": 119744,
"premine": 0,
"spaced_rune": "MNBIUEEAKPBJ",
"symbol": null,
"terms": {
"amount": 1,
"cap": 168164931,
"height": [
null,
null
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
],
[
"864333:1124",
{
"block": 864333,
"burned": 0,
"divisibility": 0,
"etching": "74e290bc2ed6b39c887ab3b456f86d91edbadb829936c63bb166d42233527491",
"mints": 0,
"number": 119743,
"burned": 0,
"divisibility": 0,
"etching": "74e290bc2ed6b39c887ab3b456f86d91edbadb829936c63bb166d42233527491",
"mints": 0,
"number": 119743,
"divisibility": 0,
"etching": "74e290bc2ed6b39c887ab3b456f86d91edbadb829936c63bb166d42233527491",
"mints": 0,
"number": 119743,
"premine": 0,
"spaced_rune": "CWTYCFSOTBSU",
"symbol": null,
"etching": "74e290bc2ed6b39c887ab3b456f86d91edbadb829936c63bb166d42233527491",
"mints": 0,
"number": 119743,
"premine": 0,
"spaced_rune": "CWTYCFSOTBSU",
"symbol": null,
"terms": {
"amount": 1,
"cap": 29807122,
"mints": 0,
"number": 119743,
"premine": 0,
"spaced_rune": "CWTYCFSOTBSU",
"symbol": null,
"terms": {
"amount": 1,
"cap": 29807122,
"premine": 0,
"spaced_rune": "CWTYCFSOTBSU",
"symbol": null,
"terms": {
"amount": 1,
"cap": 29807122,
"height": [
null,
null
"terms": {
"amount": 1,
"cap": 29807122,
"height": [
null,
null
"height": [
null,
null
null
],
],
"offset": [
null,
null
]
},
"timestamp": 1728157837,
"turbo": false
}
]
],
"more": true,
"prev": null,
"next": 1
}
GET
/sat/<SAT>
Description
Returns details about a specific satoshi. Requires index with --index-sats
flag.
Exemple
curl -s -H "Accept: application/json" \
http://0.0.0.0:80/sat/2099994106992659
{
"block": 3891094,
"charms": [],
"cycle": 3,
"decimal": "3891094.16797",
"degree": "3°111094′214″16797‴",
"epoch": 18,
"inscriptions": [],
"name": "satoshi",
"number": 2099994106992659,
"offset": 16797,
"percentile": "99.99971949060254%",
"period": 1930,
"rarity": "common",
"satpoint": null,
"timestamp": 3544214021
}
GET
/status
Description
Returns details about the server installation and index.
Exemple
curl -s -H "Accept: application/json" \
http://0.0.0.0:80/status
{
"address_index": true,
"blessed_inscriptions": 76332641,
"chain": "mainnet",
"cursed_inscriptions": 472043,
"height": 864351,
"initial_sync_time": {
"secs": 59213,
"nanos": 979632000
},
"inscriptions": 76804684,
"lost_sats": 0,
"minimum_rune_for_next_block": "PVHGFEDCAZZ",
"rune_index": true,
"runes": 119811,
"sat_index": false,
"started": "2024-09-27T17:43:39.291876400Z",
"transaction_index": false,
"unrecoverably_reorged": false,
"uptime": {
"secs": 709843,
"nanos": 910346200
}
}
GET
/tx/<TRANSACTION_ID>
Description
Returns details about the specified transaction.
Exemple
curl -s -H "Accept: application/json" \
http://0.0.0.0:80/tx/99811de396ff10152cdfc9588d9750d0151501f081df2e56071c42dc3532b743
{
"chain": "mainnet",
"etching": null,
"inscription_count": 1,
"transaction": {
"version": 2,
"lock_time": 0,
"input": [
{
"previous_output": "7d154f826f68e86370105641e3b5b1c6afc697613b8dfce48e4e40db01e8317a:1",
"script_sig": "",
"sequence": 4294967295,
"witness": [
"e68e67c60dfc06f570dfa8fe880cc09f1041a9b10b285743dd72b8f2e672987f7176ced40d46d279385c148a0c39b9914b91d9d503b7388791f6758884f0c2f4",
"200c97fe0e7bb78d8dd7447bc098386c61248e1e9a7dfd263fd828c5373b945735ac0063036f7264010109696d6167652f706e67004d080289504e470d0a1a0a0000000d49484452000000360000003608060000008c456add000000017352474200aece1ce900000306494441546881ed9abf4e1b4110c63f477903a4b4a6a04186c21532a54de1c214a432051406d14471830405a2b25cb8701344e75c43a4d0514041112843a8281c642972111ec0cfb029ec3976d7b7e7fd670cd1fe24747b6b666ebf9bbdd9b9b581402010083c93f1e5a8130d18b5776b73defcdae26500a56a8df1e73fbe7f1d3acf6404ff2f29fe9d0f27c5fcba705cdbdcc1dae60ed8086028aad1aea0d1ae18f96612ba76ef8daea24131bf8edb874b004381fd6e0f8c3136bfb46aec4bb6fbfbfba7b6ad97881d1d6e6446471c1d6e089f2d2c2f627e69d56850c0b82853bc08234ad51a00e0e63c12fa49dcf1fe95961f5ed4d3e31d9e1eef70bc7f35f6cca6e155188f2c0e001aed4aaab84e34609d6820881af51b271b6f998932a32c88a20800fd6e2f6e2709e4138b8b28600ac94397b4ece82a0a98e25424f8082e2c2fc66d1abc0cf59fd64f9cd6ba99450c508bf3c1d423362bbc444c2ea9542465ca69613d879bad0b461506210d5cf09dcd1562f17bdb07906d937cb8240f2b233e42095150facce60a8c4f202a7c88339e8aa56a8d513d68220a1866452a942962fcda46647305e7c462953c14d348ebaede3e5ca68a22b2b9020060b73627bceee862953c6ece23a1a230b505c48a24293a24cc164d44012b610917d57e0664db490bb52dffed3a1684bd3582b0b78695b0848ca5bdced0abfe246692ee6dd730575b138c23d6eff650ccaf27550d13a346b60afb18bea4b2ad15ad8a60be524f98562a9f6c643bd13fefd35698ed3396d9db3e00301ca83458a6f88b074db60adf71db657bc069974ab53325fdcf589fce0be769fd049fbe7c7e5d7b1eb6627ce26b6b20b1df568c6bb4802944eca523a3c25a98bc81f35a0411b60b74da9e8792d3fa8970feebcf3700c0d9f5bdcd3052319ec726a23ad1403857a5eeadf20a0344812e3b5480a1b049a2642180d957b25be515e6539c16cdd6052b556bacd9ba10165efaeaa7130dd8e8cec7fd36d7e17db8f8d17ec66867898e141dfe8ed29472e1ecfa3e2347ce066d611f3fe49fdb29a5ce56790580dbaf02489cad7d20100804026f9d7f6be4942aeb43f7890000000049454e44ae42608268",
"c10c97fe0e7bb78d8dd7447bc098386c61248e1e9a7dfd263fd828c5373b945735"
]
}
],
"output": [
{
"value": 546,
"script_pubkey": "51208a2ade400b30af7cae07e30a9afa8ac49f54fb3ff7d0f42bbf4a66578a34c280"
}
]
},
"txid": "99811de396ff10152cdfc9588d9750d0151501f081df2e56071c42dc3532b743"
}
Recursive Endpoints
See Recursion.
Explorateur Ordinals
The ord
binary includes a block explorer. We host an instance of the block explorer on mainnet at ordinals.com, on signet at signet.ordinals.com, and on testnet at testnet.ordinals.com. As of version 0.16.0 the wallet needs ord server
running in the background. This is analogous to how bitcoin-cli
needs bitcoind
running in the background.
Exécuter l'explorateur
Le serveur peut être exécuté localement avec :
ord server
Pour spécifier un port, ajoutez le drapeau --http-port
:
ord server --http-port 8080
The JSON-API endpoints are enabled by default, to disable them add the --disable-json-api
flag (see here for more info):
ord server --disable-json-api
Recherche
La zone de recherche accepte une variété de représentations d’objets.
Blocs
Les blocs peuvent être recherchés par hash, par exemple, le bloc genesis :
000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
Transactions
Les transactions peuvent être recherchées par hash, par exemple, la transaction coinbase du bloc genesis :
4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b
Sorties
Transaction outputs can be searched by outpoint, for example, the only output of the genesis block coinbase transaction:
4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b:0
Sats
Les sats peuvent être recherchés par nombre entier, qui représente leur position dans l’ensemble de l’offre de bitcoins :
Par nombre décimal, leur bloc et leur déplacement dans ce bloc :
Par degré sexagésimal, leur cycle, blocs depuis le dernier halving, blocs depuis le dernier ajustement de la difficulté, et déplacement dans leur bloc :
Par leur nom, leur représentation à base 26 à l’aide des lettres de « a » à « z » :
Ou par percentile, le pourcentage de l’offre de bitcoins qui a été ou sera émis une fois qu’ils auront été minés :
Wallet
Chaque sat peut être inscrit avec un contenu arbitraire, créant ainsi des artefacts numériques natifs de Bitcoin qui peuvent être stockés dans un portefeuille Bitcoin et transférés à l’aide de transactions Bitcoin. Les inscriptions sont aussi durables, immuables, sûres et décentralisées que Bitcoin lui-même.
Travailler avec des inscriptions nécessite un nœud complet Bitcoin, pour vous donner une vue d’ensemble de l’état actuel de la blockchain Bitcoin, et un portefeuille qui peut créer des inscriptions et effectuer un contrôle de sats lors de la préparation de transactions visant à envoyer des inscriptions à un autre portefeuille.
Bitcoin Core fournit à la fois un nœud complet et un portefeuille Bitcoin. Le portefeuille Bitcoin Core ne peut cependant pas créer d’inscriptions et n’effectue pas de contrôle de sats.
Pour cela, il faut recourir à ord
, l’utilitaire ordinal. ord
n’implémente pas son propre portefeuille, donc les sous-commandes du portefeuille ord wallet
interagissent avec les portefeuilles Bitcoin Core.
Ce guide couvre :
- L’installation de Bitcoin Core
- La synchronisation de la blockchain Bitcoin
- La création d’un portefeuille Bitcoin Core
- L’utilisation de
ord wallet receive
pour recevoir des sats - La création d’inscriptions à l’aide de
ord wallet inscribe
- L’envoi d’inscriptions à l’aide de
ord wallet send
- La réception d’inscriptions avec
ord wallet receive
- Batch inscribing with
ord wallet inscribe --batch
Obtenir de l’aide
Si vous êtes coincé, essayez de demander de l’aide sur le Serveur Discord d’Ordinals, ou consultez GitHub pour des discussions et des problèmes pertinents.
L’installation de Bitcoin Core
Bitcoin Core est disponible sur la page de téléchargement de bitcoincore.org.
Making inscriptions requires Bitcoin Core 28 or newer.
Ce guide ne couvre pas l’installation de Bitcoin Core en détail. Une fois Bitcoin Core installé, vous devriez être en mesure d’exécuter bitcoind -version
avec succès depuis la ligne de commande. N’utilisez PAS bitcoin-qt
.
Configurer Bitcoin Core
ord
nécessite l’index de transactions et l’interface rest de Bitcoin Core.
Pour configurer votre nœud Bitcoin Core afin qu’il maintienne un index des transactions, ajoutez ce qui suit à votre bitcoin.conf
:
txindex=1
Ou bien, exécutez bitcoind
avec -txindex
:
bitcoind -txindex
Vous pouvez trouver des détails sur la création ou la modification de votre fichier bitcoin.conf
ici.
La synchronisation de la blockchain Bitcoin
Pour synchroniser la blockchain, exécutez :
bitcoind -txindex
...et laissez-la s’exécuter jusqu’à ce que getblockcount
:
bitcoin-cli getblockcount
corresponde au nombre de blocs sur un explorateur de blocs tel que mempool.space. ord
interagit avec bitcoind
, il faut donc laisser bitcoind
s’exécuter en arrière-plan lorsque vous utilisez ord
.
La blockchain occupe environ 600 Go d’espace disque. Si vous avez un disque externe sur lequel vous souhaitez stocker des blocs, utilisez l’option de configuration blocksdir=<external_drive_path>
. C’est beaucoup plus simple que d’utiliser l’option datadir
car le fichier cookie sera toujours dans l’emplacement par défaut afin que bitcoin-cli
et ord
puissent le trouver.
Résolution des problèmes
Assurez-vous de pouvoir accéder à bitcoind
avec bitcoin-cli -getinfo
et qu’il est entièrement synchronisé.
Si bitcoin-cli -getinfo
renvoie Could not connect to the server
(n’a pas pu se connecter au serveur), bitcoind
ne s’exécute pas.
Assurez-vous que rpcuser
, rpcpassword
ou rpcauth
ne sont PAS configurés dans votre fichier bitcoin.conf
. ord
nécessite l’utilisation de l’authentification à l’aide de cookies. Assurez-vous qu’il y a un fichier .cookie
dans votre répertoire de données Bitcoin.
Si bitcoin-cli -getinfo
renvoie Could not locate RPC credentials
(n’a pas pu localiser les informations d’authentification RPC), vous devez spécifier l’emplacement du fichier cookie. Si vous utilisez un répertoire de données personnalisé (en spécifiant l’option datadir
), vous devez spécifier l’emplacement du cookie comme suit : bitcoin-cli -rpccookiefile=<your_bitcoin_datadir>/.cookie -getinfo
. Lorsque vous exécutez ord
, vous devez spécifier l’emplacement du fichier cookie à l’aide de --cookie-file=<your_bitcoin_datadir>/.cookie
.
Assurez-vous de ne PAS avoir disablewallet=1
dans votre fichier bitcoin.conf
. Si bitcoin-cli listwallets
renvoie Method not found
(méthode non trouvée), le portefeuille est désactivé et vous ne pourrez pas utiliser ord
.
Assurez-vous que txindex=1
est configuré. Lancez bitcoin-cli getindexinfo
et cela devrait retourner quelque chose de ce genre
{
"txindex": {
"synced": true,
"best_block_height": 776546
}
}
Si cela renvoie uniquement {}
, txindex
n’est pas défini. Si cela renvoie "synced": false
, bitcoind
est encore en train de créer le txindex
. Attendez que "synced": true
s’affiche avant d’utiliser ord
.
Si vous avez configuré maxuploadtarget
, cela peut interférer avec le fetch de blocs pour l’index ord
. Il faut soit le supprimer ou définir whitebind=127.0.0.1:8333
.
L’installation de ord
L’utilitaire ord
est écrit en Rust et peut être compilé à partir des sources. Des binaires préconstruits sont disponibles sur la page des versions.
Vous pouvez installer le dernier binaire préconstruit à partir de la ligne de commande suivante :
curl --proto '=https' --tlsv1.2 -fsLS https://ordinals.com/install.sh | bash -s
Une fois ord
installé, vous devriez être en mesure d’exécuter :
ord --version
Ce qui indiquera le numéro de version de ord
.
Creating a Wallet
ord
uses bitcoind
to manage private keys, sign transactions, and broadcast transactions to the Bitcoin network. Additionally the ord wallet
requires ord server
running in the background. Make sure these programs are running:
bitcoind -txindex
ord server
To create a wallet named ord
, the default, for use with ord wallet
, run:
ord wallet create
This will print out your seed phrase mnemonic, store it somewhere safe.
{
"mnemonic": "dignity buddy actor toast talk crisp city annual tourist orient similar federal",
"passphrase": ""
}
If you want to specify a different name or use an ord server
running on a non-default URL you can set these options:
ord wallet --name foo --server-url http://127.0.0.1:8080 create
To see all available wallet options you can run:
ord wallet help
Restoring and Dumping Wallet
The ord
wallet uses descriptors, so you can export the output descriptors and import them into another descriptor-based wallet. To export the wallet descriptors, which include your private keys:
$ ord wallet dump
==========================================
= THIS STRING CONTAINS YOUR PRIVATE KEYS =
= DO NOT SHARE WITH ANYONE =
==========================================
{
"wallet_name": "ord",
"descriptors": [
{
"desc": "tr([551ac972/86'/1'/0']tprv8h4xBhrfZwX9o1XtUMmz92yNiGRYjF9B1vkvQ858aN1UQcACZNqN9nFzj3vrYPa4jdPMfw4ooMuNBfR4gcYm7LmhKZNTaF4etbN29Tj7UcH/0/*)#uxn94yt5",
"timestamp": 1296688602,
"active": true,
"internal": false,
"range": [
0,
999
],
"next": 0
},
{
"desc": "tr([551ac972/86'/1'/0']tprv8h4xBhrfZwX9o1XtUMmz92yNiGRYjF9B1vkvQ858aN1UQcACZNqN9nFzj3vrYPa4jdPMfw4ooMuNBfR4gcYm7LmhKZNTaF4etbN29Tj7UcH/1/*)#djkyg3mv",
"timestamp": 1296688602,
"active": true,
"internal": true,
"range": [
0,
999
],
"next": 0
}
]
}
An ord
wallet can be restored from a mnemonic:
ord wallet restore --from mnemonic
Type your mnemonic and press return.
To restore from a descriptor in descriptor.json
:
cat descriptor.json | ord wallet restore --from descriptor
To restore from a descriptor in the clipboard:
ord wallet restore --from descriptor
Paste the descriptor into the terminal and press CTRL-D on unix and CTRL-Z on Windows.
Recevoir des sats
Les inscriptions sont créées sur des sats individuels, en utilisant des transactions Bitcoin standard qui paient des frais en sats. Votre portefeuille doit donc contenir quelques sats.
Obtenez une nouvelle adresse à partir de votre portefeuille ord
en exécutant :
ord wallet receive
Et envoyez-y des fonds.
Vous pouvez voir les transactions en attente en exécutant :
ord wallet transactions
Une fois la transaction confirmée, vous devriez être en mesure de voir les sorties de transactions avec ord wallet outputs
.
Créer du contenu pour les inscriptions
Les sats peuvent être inscrits avec n’importe quel type de contenu, mais le portefeuille ord
ne prend en charge que les types de contenu qui peuvent être affichés par l’explorateur de blocs ord
.
En outre, les inscriptions sont incluses dans les transactions, donc plus le contenu est volumineux, plus les frais à payer pour la transaction de l’inscription sont élevés.
Le contenu des inscriptions est inclus dans les témoins de transaction, qui bénéficient de la réduction pour témoins. Afin de calculer le montant approximatif des frais de transaction d’une inscription, divisez la taille du contenu par quatre et multipliez par le taux de frais.
Les transactions d’inscription doivent être inférieures à 400 000 unités de poids, sinon elles ne seront pas relayées par Bitcoin Core. Un octet de contenu d’inscription coûte une unité de poids. Étant donné qu’une transaction d’inscription ne contient pas seulement le contenu de l’inscription, il faut limiter le contenu de l’inscription à moins de 400 000 unités de poids. Il est donc recommandé de ne pas dépasser 390 000 unités de poids, afin de maintenir une marge de sécurité.
La création d’inscriptions
Pour créer une inscription avec le contenu de FILE
, exécutez :
ord wallet inscribe --fee-rate FEE_RATE --file FILE
Ord affichera deux identifiants de transaction, l’un pour la transaction d’engagement et l’autre pour la transaction de révélation, ainsi que l’identifiant de l’inscription. Les identifiants d’inscription ont le format TXIDiN
, TXID
étant l’identifiant de la transaction de révélation et N
l’index de l’inscription dans la transaction de révélation.
La transaction d’engagement s’engage à utiliser un tapscript qui héberge le contenu de l’inscription, tandis que la transaction de révélation dépense ce tapscript, révélant ainsi le contenu sur la chaîne et l’inscrivant sur le premier sat d’entrée contenant le tapscript correspondant.
Attendez que la transaction de révélation soit minée. Vous pouvez vérifier le statut des transactions d’engagement et de révélation en utilisant l’explorateur de blocs mempool.space.
Une fois que la transaction de révélation a été minée, l’identifiant d’inscription devrait apparaître lorsque vous exécutez :
ord wallet inscriptions
Inscriptions parent-enfant
Les inscriptions parent-enfant permettent ce que l’on appelle des collections en langage courant (voir provenance pour plus d’informations).
Pour faire d’une inscription l’enfant d’une autre, l’inscription parent doit être inscrite et présente dans le portefeuille. Pour choisir un parent, lancez ord wallet inscriptions
et copiez l’identifiant de l’inscription (<PARENT_INSCRIPTION_ID>
).
Inscrivez maintenant l’inscription enfant et spécifiez le parent comme suit :
ord wallet inscribe --fee-rate FEE_RATE --parent <PARENT_INSCRIPTION_ID> --file CHILD_FILE
Cette relation ne peut pas être ajoutée rétroactivement, le parent doit être présent lors de la création de l’enfant.
L’envoi d’inscriptions
Demandez au destinataire de générer une nouvelle adresse en exécutant :
ord wallet receive
Envoyez l’inscription en exécutant :
ord wallet send --fee-rate <FEE_RATE> <ADDRESS> <INSCRIPTION_ID>
Voyez la transaction en attente avec la commande :
ord wallet transactions
Une fois que la transaction d’envoi est confirmée, le destinataire peut confirmer la réception en exécutant :
ord wallet inscriptions
Sending Runes
Demandez au destinataire de générer une nouvelle adresse en exécutant :
ord wallet receive
Send the runes by running:
ord wallet send --fee-rate <FEE_RATE> <ADDRESS> <RUNES_AMOUNT>
Where RUNES_AMOUNT
is the number of runes to send, a :
character, and the name of the rune. For example if you want to send 1000 of the EXAMPLE rune, you would use 1000:EXAMPLE
.
ord wallet send --fee-rate 1 SOME_ADDRESS 1000:EXAMPLE
Voyez la transaction en attente avec la commande :
ord wallet transactions
Once the send transaction confirms, the recipient can confirm receipt with:
ord wallet balance
La réception d’inscriptions
Générez une nouvelle adresse de réception en utilisant :
ord wallet receive
L’expéditeur peut transférer l’inscription à votre adresse en utilisant :
ord wallet send --fee-rate <FEE_RATE> ADDRESS INSCRIPTION_ID
Voyez la transaction en attente avec la commande :
ord wallet transactions
Once the send transaction confirms, you can confirm receipt by running:
ord wallet inscriptions
Batch Inscribing
Multiple inscriptions can be created at the same time using the pointer field. This is especially helpful for collections, or other cases when multiple inscriptions should share the same parent, since the parent can passed into a reveal transaction that creates multiple children.
To create a batch inscription using a batchfile in batch.yaml
, run the following command:
ord wallet batch --fee-rate 21 --batch batch.yaml
Example batch.yaml
# example batch file
# inscription modes:
# - `same-sat`: inscribe on the same sat
# - `satpoints`: inscribe on the first sat of specified satpoint's output
# - `separate-outputs`: inscribe on separate postage-sized outputs
# - `shared-output`: inscribe on a single output separated by postage
mode: separate-outputs
# parent inscriptions:
parents:
- 6ac5cacb768794f4fd7a78bf00f2074891fce68bd65c4ff36e77177237aacacai0
# postage for each inscription:
postage: 12345
# allow reinscribing
reinscribe: true
# sat to inscribe on, can only be used with `same-sat`:
# sat: 5000000000
# rune to etch (optional)
etching:
# rune name
rune: THE•BEST•RUNE
# allow subdividing super-unit into `10^divisibility` sub-units
divisibility: 2
# premine
premine: 1000.00
# total supply, must be equal to `premine + terms.cap * terms.amount`
supply: 10000.00
# currency symbol
symbol: $
# mint terms (optional)
terms:
# amount per mint
amount: 100.00
# maximum number of mints
cap: 90
# mint start and end absolute block height (optional)
height:
start: 840000
end: 850000
# mint start and end block height relative to etching height (optional)
offset:
start: 1000
end: 9000
# future runes protocol changes may be opt-in. this may be for a variety of
# reasons, including that they make light client validation harder, or simply
# because they are too degenerate.
#
# setting `turbo` to `true` opts in to these future protocol changes,
# whatever they may be.
turbo: true
# inscriptions to inscribe
inscriptions:
# path to inscription content
- file: mango.avif
# inscription to delegate content to (optional)
delegate: 6ac5cacb768794f4fd7a78bf00f2074891fce68bd65c4ff36e77177237aacacai0
# destination (optional, if no destination is specified a new wallet change address will be used)
destination: bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4
# inscription metadata (optional)
metadata:
title: Delicious Mangos
description: >
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aliquam semper,
ligula ornare laoreet tincidunt, odio nisi euismod tortor, vel blandit
metus est et odio. Nullam venenatis, urna et molestie vestibulum, orci
mi efficitur risus, eu malesuada diam lorem sed velit. Nam fermentum
dolor et luctus euismod.
- file: token.json
# inscription metaprotocol (optional)
metaprotocol: DOPEPROTOCOL-42069
- file: tulip.png
destination: bc1pdqrcrxa8vx6gy75mfdfj84puhxffh4fq46h3gkp6jxdd0vjcsdyspfxcv6
metadata:
author: Satoshi Nakamoto
- file: gallery.png
# gallery items
gallery:
- a4676e57277b70171d69dc6ad2781485b491fe0ff5870f6f6b01999e7180b29ei0
- a4676e57277b70171d69dc6ad2781485b491fe0ff5870f6f6b01999e7180b29ei3
Splitting
Complex transactions can be created using the ord wallet split
command.
The split
command takes a YAML configuration file, which specifies any number of outputs to be created, their bitcoin value, and their value of any number of runes. It does not currently allow assigning inscriptions to outputs.
The split
command can be used to split cardinal, bitcoin-only outputs for transacting, distribute runes to large numbers of recipients in a single transaction.
To send a split transaction using the configuration in splits.yaml
, run the following command:
ord wallet split --fee-rate 21 --splits split.yaml
Example splits.yaml
--------------------`
# example split file
# output fields:
# address: output recipient bitcoin address
# value: output bitcoin value (optional, defaults to minimal-non dust value for `address`)
# runes: output rune value map (values respect rune divisibility)
outputs:
- address: bc1p5d7rjq7g6rdk2yhzks9smlaqtedr4dekq08ge8ztwac72sfr9rusxg3297
value: 10 sat
runes:
UNCOMMON•GOODS: 1234
GRIEF•WAGE: 5000000
- address: 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy
runes:
HELLO•WORLD: 22.5
Collectionner
Actuellement, ord est le seul portefeuille qui prend en charge le contrôle et la sélection des sats, ce qui est indispensable pour stocker et envoyer en toute sécurité des sats et des inscriptions rares, ci-après dénommés « ordinals ».
Il est recommandé d’envoyer, de recevoir et de stocker les ordinals avec ord
, mais si vous êtes prudent, il est possible de stocker, et dans certains cas d’envoyer, des ordinals en toute sécurité au moyen d’autres portefeuilles.
D’une manière générale, recevoir des ordinals dans un portefeuille non pris en charge n’est pas dangereux. Les ordinals peuvent être envoyés à n’importe quelle adresse bitcoin et sont sûrs tant que l’UTXO qui les contient n’est pas dépensé. En revanche, si ce portefeuille est ensuite utilisé pour envoyer des bitcoins, il se peut que l’UTXO contenant l’ordinal soit sélectionné comme entrée et que l’inscription soit envoyée par erreur ou qu’elle soit dépensée en frais.
Un guide pour créer un portefeuille compatible avec ord
à l’aide d’un portefeuille Sparrow, est disponible dans ce manuel.
Veuillez noter que si vous suivez ce guide, vous ne devriez pas utiliser le portefeuille que vous avez créé pour envoyer des BTC, à moins que vous ne procédiez à une sélection manuelle de monnaie pour éviter d’envoyer des ordinals par erreur.
Collectionner des inscriptions et des ordinals avec le portefeuille Sparrow
Les utilisateurs qui ne peuvent pas ou n’ont pas encore mis en place le portefeuille ordpeuvent recevoir des inscriptions et des ordinals en utilisant d’autres portefeuilles Bitcoin, à condition qu’ils soient très prudents à la manière dont ils dépensent l’argent de ce portefeuille.
Ce guide fournit des instructions de base pour créer un portefeuille avec Sparrow Wallet qui soit compatible avec ord
et qui puisse être importé dans ord par la suite
⚠️⚠️ Avertissement!! ⚠️⚠️
En règle générale, si vous adoptez cette approche, vous devriez utiliser ce portefeuille avec le logiciel Sparrow uniquement en tant que portefeuille de réception.
Ne dépensez pas de satoshis à partir de ce portefeuille à moins d’être sûr de savoir ce que vous faites. Vous pourriez très facilement perdre l’accès à vos ordinals et à vos inscriptions par inadvertance si vous ne tenez pas compte de cet avertissement.
Configuration du portefeuille et réception
Téléchargez Sparrow Wallet à partir de la page de téléchargement correspondant à votre système d’exploitation.
Sélectionnez File -> New Wallet
et créez un nouveau portefeuille appelé ord
.
Modifiez le Script Type
(type de script) en choisissant Taproot (P2TR)
et sélectionnez l’option New or Imported Software Wallet
(Portefeuille de logiciel nouveau ou importé).
Sélectionnez Use 12 Words
(utiliser 12 mots), puis cliquez sur Generate New
(Créer nouveau). Laissez la passphrase (phrase secrète) vide.
Une nouvelle phrase de récupération BIP39 contenant 12 mots sera générée pour vous. Notez-la dans un endroit sûr, car elle vous servira de référence pour accéder à votre portefeuille. Ne communiquez ou ne montrez JAMAIS cette phrase de récupération à qui que ce soit.
Une fois que vous avez noté la phrase de récupération, cliquez sur Confirm Backup
(confirmer la sauvegarde).
Saisissez à nouveau la phrase de récupération que vous avez notée, puis cliquez sur Create Keystore
(Créer le Keystore).
Cliquez sur Import Keystore
.(Importer le Keystore).
Cliquez sur Apply
(Appliquer). Ajoutez un mot de passe pour le portefeuille si vous le souhaitez.
Vous disposez maintenant d’un portefeuille compatible avec ord
, qui peut être importé dans ord
à l’aide de la phrase de récupération BIP39. Pour recevoir des ordinals ou des inscriptions, cliquez sur l’onglet Receive
(recevoir) et copiez une nouvelle adresse.
Chaque fois que vous voulez recevoir, vous devriez utiliser une toute nouvelle adresse et ne pas réutiliser les adresses existantes.
Veuillez noter que le portefeuille Bitcoin est différent de certains autres portefeuilles de blockchain dans la mesure où il peut générer un nombre illimité de nouvelles adresses. Vous pouvez générer une nouvelle adresse en cliquant sur le bouton Get Next Address
(Obtenir l’adresse suivante). Vous pouvez voir toutes vos adresses dans l’onglet Addresses
(Adresses) de l’application.
Vous pouvez ajouter une étiquette à chaque adresse, afin de garder une trace de sa fonction ou de son utilisation.
Validation / visualisation des inscriptions reçues
Une fois que vous avez reçu une inscription, vous verrez une nouvelle transaction dans l’onglet Transactions
de Sparrow, ainsi qu’un nouvel UTXO dans l’onglet UTXOs
.
Au départ, cette transaction peut avoir un statut « non confirmé », et vous devrez attendre qu’elle soit minée dans un bloc de bitcoins avant de la recevoir dans son intégralité.
Pour suivre le statut de votre transaction, vous pouvez faire un clic droit dessus, sélectionner Copy Transaction ID
(Copier l’identifiant de la transaction) et ensuite coller cet identifiant de transaction dans mempool.space.
Une fois la transaction confirmée, vous pouvez valider et visualiser votre inscription en allant dans l’onglet UTXOs
, en trouvant l’UTXO que vous souhaitez vérifier, en faisant un clic droit sur Output
(sortie) et en sélectionnant Copy Transaction Output
(Copier sortie de transaction). Cet identifiant de sortie de transaction peut ensuite être collé dans le champ de recherche sur ordinals.com](https://ordinals.com).
Gel des UTXOs
Comme expliqué ci-dessus, chacune de vos inscriptions est stockée dans une sortie de transaction non dépensée (UTXO). Vous devez faire très attention à ne pas dépenser accidentellement vos inscriptions. Une façon d’éviter cela est de geler l’UTXO correspondant.
Pour ce faire, allez dans l’onglet UTXOs
, trouvez l’UTXO que vous voulez geler, faites un clic droit sur Output
et sélectionnez Freeze UTXO
(congeler UTXO).
Cet UTXO (Inscription) dans le portefeuille Sparrow ne pourra pas être dépensé jusqu’à ce que vous le dégeliez.
Importation dans le portefeuille ord
For details on setting up Bitcoin Core and the ord
wallet check out the Wallet Guide
Lors de la configuration d’ord
, au lieu d’exécuter ord wallet create
pour créer un nouveau portefeuille, vous pouvez importer votre portefeuille existant en utilisant ord wallet restore "BIP39 SEED PHRASE"
avec la phrase de récupération que vous avez générée dans le portefeuille Sparrow.
Il existe actuellement un bug qui empêche un portefeuille importé d’être re-scanné automatiquement pour trouver son contenu sur la blockchain. Pour contourner ce problème, vous devrez manuellement déclencher un rescan à l’aide de bitcoin core cli: bitcoin-cli -rpcwallet=ord rescanblockchain 767430
Vous pouvez ensuite vérifier les inscriptions de votre portefeuille en utilisant ord wallet inscriptions
Notez que si vous avez précédemment créé un portefeuille avec ord
, vous aurez alors déjà un portefeuille avec le nom par défaut, et vous devrez donner un nom différent à votre portefeuille importé. Vous pouvez utiliser le paramètre --wallet
dans toutes les commandes ord
pour référencer un portefeuille différent, par exemple :
ord wallet --name ord_from_sparrow wallet restore --from mnemonic
ord wallet --name ord_from_sparrow wallet inscriptions
bitcoin-cli -rpcwallet=ord_from_sparrow rescanblockchain 767430
Envoyer des inscriptions avec le portefeuille Sparrow
⚠️⚠️ Avertissement ⚠️⚠️
Bien qu’il soit fortement recommandé de mettre en place un nœud Bitcoin Core et d’exécuter le logiciel ord
, il existe quelques moyens limités d’envoyer des inscriptions à partir du portefeuille Sparrow en toute sécurité. Veuillez noter que cela n’est pas recommandé et que vous ne devez le faire que si vous comprenez parfaitement ce que vous faites.
Le fait d’utiliser le logiciel ord
supprimera une grande partie de la complexité que nous décrivons ici, car il est capable de gérer automatiquement et en toute sécurité l’envoi d’inscriptions de manière simple.
⚠️⚠️ Avertissement supplémentaire ⚠️⚠️
N’utilisez pas votre portefeuille d’inscriptions Sparrow pour effectuer des transactions de bitcoins qui n’impliquent pas des inscriptions. Vous pouvez créer un portefeuille séparé dans Sparrow pour gérer vos transactions régulières de bitcoins, et maintenir votre portefeuille d’inscriptions séparé.
Le modèle UTXO de Bitcoin
Avant d’envoyer une transaction, il est important que vous ayez une bonne compréhension du système UTXO (Unspent Transaction Output) de Bitcoin. Le fonctionnement du Bitcoin est fondamentalement différent de celui de nombreuses autres blockchains telles que Ethereum. Sur Ethereum, vous avez généralement une seule adresse dans laquelle vous stockez l’ETH, et vous ne pouvez pas faire de distinction entre chacun des ETH – il s’agit simplement d’une valeur unique du montant total dans cette adresse. Bitcoin fonctionne très différemment dans la mesure où nous générons une nouvelle adresse dans le portefeuille pour chaque réception, et chaque fois que vous recevez des sats à une adresse de votre portefeuille, vous créez un nouvel UTXO. Chaque UTXO peut être consulté et géré individuellement. Vous pouvez sélectionner des UTXOs spécifiques que vous souhaitez dépenser, et vous pouvez choisir de ne pas dépenser certains UTXOs.
Certains portefeuilles Bitcoin n’exposent pas ce niveau de détail et se contentent d’afficher une valeur unique correspondant à l’ensemble des bitcoins dans votre portefeuille. Cependant, lorsque vous envoyez des inscriptions, il est important que vous utilisiez un portefeuille comme Sparrow qui permet le contrôle d’UTXOs.
Inspecter son inscription avant de l’envoyer
Comme décrit ci-dessus, les inscriptions sont inscrites sur des sats, et les sats sont stockés dans des UTXOs. Les UTXOs sont une collection de satoshis avec une valeur particulière du nombre de satoshis (la valeur de sortie). En général (mais pas toujours), l’inscription est inscrite sur le premier satoshi de l’UTXO.
Lorsque vous inspectez votre inscription avant de l’envoyer, la principale chose à vérifier est sur quel satoshi de l’UTXO votre inscription est inscrite.
Pour ce faire, vous pouvez suivre la procédure de validation / visualisation des inscriptions reçues décrite ci-dessus pour trouver la page d’inscription de votre inscription sur ordinals.com
Vous y trouverez des métadonnées sur votre inscription qui ressemblent à ce qui suit :
Il y a plusieurs points importants à vérifier à ce stade :
- L’identifiant
output
correspond à l’identifiant de l’UTXO que vous allez envoyer. - Le
offset
(déplacement) de l’inscription correspond à0
(cela signifie que l’inscription est située sur le premier sat de l’UTXO) - la valeur
output_value
contient suffisamment de sats pour couvrir les frais de transaction (postage) liés à l’envoi de la transaction. Le montant exact dont vous aurez besoin dépend du taux de frais que vous choisirez pour la transaction
Si tous les points ci-dessus s’appliquent à votre inscription, vous pouvez l’envoyer en toute sécurité en utilisant la méthode ci-dessous.
⚠️⚠️ Soyez très prudent lorsque vous envoyez votre inscription, en particulier si la valeur offset
est différente de 0. Il n’est pas recommandé d’utiliser cette méthode si c’est le cas, car vous pourriez accidentellement envoyer votre inscription à un mineur de bitcoins, à moins que vous ne sachiez ce que vous faites.
Envoyer votre inscription
Pour envoyer une inscription, allez dans l’onglet UTXOs
et recherchez l’UTXO que vous avez validé précédemment comme contenant votre inscription.
Si vous avez précédemment gelé cet UTXO, vous devrez faire un clic droit dessus et le dégeler.
Sélectionnez l’UTXO que vous souhaitez envoyer et assurez-vous que c’est le seul UTXO sélectionné. Vous devriez voir UTXOs 1/1
dans l’interface. Une fois que vous êtes absolument sûr d’avoir sélectionné le bon UTXO, vous pouvez cliquer sur Send Selected
(envoyer la sélection).
Vous verrez alors apparaître l’interface de construction de transactions. Il y a quelques points que vous devez vérifier ici pour vous assurer que cet envoi est sûr :
- La transaction ne doit avoir que 1 input (entrée), et celle-ci doit être l’UTXO avec l’étiquette que vous voulez envoyer.
- La transaction ne doit avoir que 1 output (sortie), qui est l’adresse/l’étiquette où vous voulez envoyer l’inscription
Si votre transaction semble différente, par exemple si elle a plusieurs entrées ou plusieurs sorties, il se peut que le transfert de votre inscription ne soit pas sûr et que vous deviez renoncer à l’envoyer jusqu’à ce que vous en sachiez plus ou jusqu’à ce que vous puissiez l’importer dans le portefeuille ord
.
Vous devez fixer des frais de transaction appropriés. Sparrow en recommande généralement des raisonnables, mais vous pouvez également consulter mempool.space pour voir quel taux de frais est recommandé pour l’envoi d’une transaction.
Vous devriez ajouter une étiquette pour l’adresse du destinataire ; une étiquette telle que alice address for inscription #123
(adresse Alice pour inscription #123) serait idéal.
Une fois que vous avez vérifié que la transaction est sûre en utilisant les critères mentionnés ci-dessus, et que vous êtes confiant pour l’envoyer, vous pouvez cliquer sur Create Transaction
(créer transaction).
Ici, vous pouvez à nouveau vérifier que votre transaction semble sûre et, une fois que vous êtes sûr de vous, vous pouvez cliquer sur Finalize Transaction for Signing
(Finaliser la transaction pour la signer).
Ici, vous pouvez tout vérifier une troisième fois avant de cliquer sur Sign
(Signer).
Ensuite, vous avez en réalité une toute dernière chance de tout vérifier avant de cliquer sur Broadcast Transaction
(Diffuser la transaction). Une fois la transaction diffusée, elle est envoyée au réseau Bitcoin et commence à se propager dans le mempool.
Si vous souhaitez suivre l’état de votre transaction, vous pouvez copier Transaction Id (Txid)
(l’identifiant de transaction) et le coller dans mempool.space
Une fois la transaction confirmée, vous pouvez consulter la page d’inscriptions sur ordinals.com pour vérifier qu’elle a bien été transférée vers le nouvel emplacement de sortie et la nouvelle adresse.
Résolution des problèmes
Le portefeuille Sparrow n’affiche pas une transaction/UTXO, mais je peux la voir sur mempool.space !
Assurez-vous que votre portefeuille est connecté à un nœud Bitcoin. Pour valider cela, allez dans les paramètres Preferences
-> Server
, et cliquez sur Edit Existing Connection
(Modifier connexion existante).
De là, vous pouvez sélectionner un nœud et cliquer sur Test Connection
(Tester connexion) pour valider que Sparrow est capable de se connecter avec succès.
Modération
ord
comprend un explorateur de blocs, que vous pouvez exécuter localement avec ord server
.
L'explorateur de blocs permet de visualiser les inscriptions. Les inscriptions sont des contenus générés par les utilisateurs, qui peuvent être répréhensibles ou illicites.
Il incombe à chaque personne qui lance une instance de l'explorateur de blocs ordinal de comprendre ses responsabilités en matière de contenu illicite et de décider de la politique de modération appropriée pour son instance.
Afin d'empêcher que certaines inscriptions soient affichées sur une instance ord
, elles peuvent être incluses dans un fichier de configuration YAML, qui est chargé avec l'option --config
.
Pour masquer des inscriptions, créez d'abord un fichier de configuration, avec l'identifiant de l'inscription que vous souhaitez masquer :
hidden:
- 0000000000000000000000000000000000000000000000000000000000000000i0
Le nom suggéré pour les fichiers de configuration ord
est ord.yaml
, mais n'importe quel nom de fichier peut être utilisé.
Passez ensuite le fichier à --config
lorsque vous démarrez le serveur :
ord --config ord.yaml server
Notez que l'option --config
vient après ord
mais avant la sous-commande server
.
ord
doit être redémarré pour que les modifications apportées au fichier de configuration soient prises en compte.
ordinals.com
Les instances de ordinals.com
utilisent systemd
pour exécuter le service ord server
, appelé ord
, avec un fichier de configuration situé dans /var/lib/ord/ord.yaml
.
Pour masquer une inscription sur ordinals.com
:
- Connectez-vous en SSH au serveur
- Ajoutez l'identifiant de l'inscription à
/var/lib/ord/ord.yaml
- Redémarrez le service avec
systemctl restart ord
- Surveillez le redémarrage avec
journalctl -u ord
Actuellement, ord
est lent à redémarrer, le site ne sera donc pas remis en ligne immédiatement.
Réindexation
Parfois, la base de données ord
doit être réindexée, ce qui signifie qu'il faut supprimer la base de données et relancer le processus d'indexation, soit avec ord index update
, soit avec ord server
. Les raisons qui justifient la réindexation sont les suivantes :
- Il existe une nouvelle version importante d’ord, qui modifie le schéma de la base de données
- La base de données a été corrompue d'une certaine manière
La base de données utilisée par ord s'appelle redb, et l'index se voit donc attribué le nom de fichier par défaut index.redb
. Ce fichier est sauvegardé par défaut à différents endroits en fonction de votre système d'exploitation.
Plateforme | Valeur | Exemple |
---|---|---|
Linux | $XDG_DATA_HOME /ord ou $HOME /.local/share/ord | /home/alice/.local/share/ord |
macOS | $HOME /Library/Application Support/ord | /Users/Alice/Library/Application Support/ord |
Windows | {FOLDERID_RoamingAppData} \ord | C:\Users\Alice\AppData\Roaming\ord |
Ainsi, pour supprimer la base de données et la réindexer sur MacOS, vous devriez exécuter les commandes suivantes dans le terminal :
rm ~/Library/Application Support/ord/index.redb
ord index update
Vous pouvez bien sûr aussi définir ord --datadir <DIR> index update
ou lui donner un nom de fichier et un chemin d’accès spécifiques avec ord --index <FILENAME> index update
.
Chasse aux sats
La chasse d’Ordinals est difficile mais gratifiante. Le sentiment de posséder un portefeuille rempli d’UTXOs, imprégné de l’odeur de sats rares et exotiques, est incomparable.
Les ordinals sont des nombres pour les satoshis. Chaque satoshi a un nombre ordinal et chaque nombre ordinal a un satoshi.
Préparation
Avant de commencer il vous faudra certaines choses.
-
Tout d’abord, vous aurez besoin d’un nœud Bitcoin Core synchronisé avec un index de transaction. Pour activer l’indexation des transactions, exécutez
-txindex
en ligne de commande :bitcoind -txindex
Ou ajoutez ce qui suit dans votre fichier de configuration Bitcoin :
txindex=1
Exécutez cette commande et attendez qu’elle rattrape le bout de la chaîne. Une fois cela fait, la commande suivante devrait vous indiquer la hauteur du bloc actuel :
bitcoin-cli getblockcount
-
Deuxièmement, vous aurez besoin d’un index
ord
synchronisé.-
Obtenez une copie d’
ord
depuis le référentiel. -
Run
ord --index-sats server
. It should connect to your bitcoin core node and start indexing. -
Once it has finished indexing, leave the server running and submit new
ord
commands in a separate terminal session.
-
-
Troisièmement, vous aurez besoin d’un portefeuille avec les UTXOs que vous souhaitez rechercher.
Rechercher des ordinals rares
Rechercher des ordinals rares dans un portefeuille Bitcoin Core
La commande ord wallet
n’est qu’une enveloppe autour de l’API RPC de Bitcoin Core, donc la recherche d’ordinals rares dans un portefeuille Bitcoin Core est facile. Supposons que votre portefeuille s’appelle foo
:
-
Chargez votre portefeuille :
bitcoin-cli loadwallet foo
-
Affichez tous les UTXOs rares du portefeuille d’ordinals
foo
:ord --index-sats wallet --name foo sats
Rechercher des ordinals rares dans un portefeuille autre que Bitcoin Core
La commande ord wallet
n’est qu’une enveloppe autour de l’API RPC de Bitcoin Core, donc pour rechercher des ordinals rares dans un portefeuille autre que Bitcoin Core, vous devrez importer les descripteurs de votre portefeuille dans Bitcoin Core.
Les descripteurs décrivent la façon dont les portefeuilles génèrent les clés privées et les clés publiques.
Vous devrez uniquement importer les descripteurs des clés publiques de votre portefeuille dans Bitcoin Core, pas ceux des clés privées.
Si le descripteur de la clé publique de votre portefeuille est compromis, un attaquant pourra voir les adresses de votre portefeuille, mais vos fonds seront en sécurité.
Si le descripteur de la clé privée de votre portefeuille est compromis, un attaquant peut vider votre portefeuille de ses fonds.
-
Obtenez le descripteur du portefeuille contenant les UTXOs que vous voulez analyser pour identifier s’ils contiennent des ordinals rares. Il ressemblera à quelque chose comme ceci :
wpkh([bf1dd55e/84'/0'/0']xpub6CcJtWcvFQaMo39ANFi1MyXkEXM8T8ZhnxMtSjQAdPmVSTHYnc8Hwoc11VpuP8cb8JUTboZB5A7YYGDonYySij4XTawL6iNZvmZwdnSEEep/0/*)#csvefu29
-
Créez un portefeuille en lecture seule nommé
foo-watch-only
:bitcoin-cli createwallet foo-watch-only true true
N’hésitez pas à lui donner un meilleur nom que
foo-watch-only
! -
Chargez le Portefeuille
foo-watch-only
:bitcoin-cli loadwallet foo-watch-only
-
Importez les descripteurs de votre portefeuille dans
foo-watch-only
:bitcoin-cli importdescriptors \ '[{ "desc": "wpkh([bf1dd55e/84h/0h/0h]xpub6CcJtWcvFQaMo39ANFi1MyXkEXM8T8ZhnxMtSjQAdPmVSTHYnc8Hwoc11VpuP8cb8JUTboZB5A7YYGDonYySij4XTawL6iNZvmZwdnSEEep/0/*)#tpnxnxax", "timestamp":0 }]'
Si vous connaissez l’heure Unix à laquelle votre portefeuille a commencé à recevoir des transactions, vous pouvez l’utiliser comme valeur de
"timestamp"
au lieu de 0. Cela réduira le temps que Bitcoin Core prendra pour rechercher des UTXOs dans votre portefeuille. -
Vérifiez que tout a fonctionné correctement :
bitcoin-cli getwalletinfo
-
Affichez les ordinals rares qui se trouvent dans votre portefeuille :
ord wallet sats
Rechercher des ordinals rares dans un portefeuille qui exporte des descripteurs à chemins multiples (multi-path)
Certains descripteurs décrivent plusieurs chemins dans un seul descripteur en utilisant des crochets angulaires, par exemple <0;1>
. Les descripteurs à chemins multiples ne sont pas encore pris en charge par Bitcoin Core, vous devrez donc d’abord les convertir en descripteurs multiples, puis importer ces descripteurs multiples dans Bitcoin Core.
-
Obtenez d’abord le descripteur à chemins multiples de votre portefeuille. Il ressemblera à quelque chose comme ceci :
wpkh([bf1dd55e/84h/0h/0h]xpub6CcJtWcvFQaMo39ANFi1MyXkEXM8T8ZhnxMtSjQAdPmVSTHYnc8Hwoc11VpuP8cb8JUTboZB5A7YYGDonYySij4XTawL6iNZvmZwdnSEEep/<0;1>/*)#fw76ulgt
-
Créez un descripteur pour le chemin de l’adresse de réception :
wpkh([bf1dd55e/84'/0'/0']xpub6CcJtWcvFQaMo39ANFi1MyXkEXM8T8ZhnxMtSjQAdPmVSTHYnc8Hwoc11VpuP8cb8JUTboZB5A7YYGDonYySij4XTawL6iNZvmZwdnSEEep/0/*)
Et pour le chemin de l’adresse qui recevra la monnaie restante (change address) :
wpkh([bf1dd55e/84'/0'/0']xpub6CcJtWcvFQaMo39ANFi1MyXkEXM8T8ZhnxMtSjQAdPmVSTHYnc8Hwoc11VpuP8cb8JUTboZB5A7YYGDonYySij4XTawL6iNZvmZwdnSEEep/1/*)
-
Obtenez et notez la somme de contrôle du descripteur d’adresse de réception, dans ce cas
tpnxnxax
:bitcoin-cli getdescriptorinfo \ 'wpkh([bf1dd55e/84h/0h/0h]xpub6CcJtWcvFQaMo39ANFi1MyXkEXM8T8ZhnxMtSjQAdPmVSTHYnc8Hwoc11VpuP8cb8JUTboZB5A7YYGDonYySij4XTawL6iNZvmZwdnSEEep/0/*)'
{ "descriptor": "wpkh([bf1dd55e/84'/0'/0']xpub6CcJtWcvFQaMo39ANFi1MyXkEXM8T8ZhnxMtSjQAdPmVSTHYnc8Hwoc11VpuP8cb8JUTboZB5A7YYGDonYySij4XTawL6iNZvmZwdnSEEep/0/*)#csvefu29", "checksum": "tpnxnxax", "isrange": true, "issolvable": true, "hasprivatekeys": false }
Et pour le descripteur de l’adresse qui recevra la monnaie restante (change address), dans ce cas
64k8wnd7
:bitcoin-cli getdescriptorinfo \ 'wpkh([bf1dd55e/84h/0h/0h]xpub6CcJtWcvFQaMo39ANFi1MyXkEXM8T8ZhnxMtSjQAdPmVSTHYnc8Hwoc11VpuP8cb8JUTboZB5A7YYGDonYySij4XTawL6iNZvmZwdnSEEep/1/*)'
{ "descriptor": "wpkh([bf1dd55e/84'/0'/0']xpub6CcJtWcvFQaMo39ANFi1MyXkEXM8T8ZhnxMtSjQAdPmVSTHYnc8Hwoc11VpuP8cb8JUTboZB5A7YYGDonYySij4XTawL6iNZvmZwdnSEEep/1/*)#fyfc5f6a", "checksum": "64k8wnd7", "isrange": true, "issolvable": true, "hasprivatekeys": false }
-
Chargez le portefeuille dans lequel vous souhaitez importer les descripteurs :
bitcoin-cli loadwallet foo-watch-only
-
Importez maintenant les descripteurs, avec les sommes de contrôle correctes, dans Bitcoin Core.
bitcoin-cli \ importdescriptors \ '[ { "desc": "wpkh([bf1dd55e/84h/0h/0h]xpub6CcJtWcvFQaMo39ANFi1MyXkEXM8T8ZhnxMtSjQAdPmVSTHYnc8Hwoc11VpuP8cb8JUTboZB5A7YYGDonYySij4XTawL6iNZvmZwdnSEEep/0/*)#tpnxnxax" "timestamp":0 }, { "desc": "wpkh([bf1dd55e/84h/0h/0h]xpub6CcJtWcvFQaMo39ANFi1MyXkEXM8T8ZhnxMtSjQAdPmVSTHYnc8Hwoc11VpuP8cb8JUTboZB5A7YYGDonYySij4XTawL6iNZvmZwdnSEEep/1/*)#64k8wnd7", "timestamp":0 } ]'
Si vous connaissez l’heure Unix à laquelle votre portefeuille a commencé à recevoir des transactions, vous pouvez l’utiliser comme valeur de
"timestamp"
au lieu de0
. Cela réduira le temps que Bitcoin Core prendra pour rechercher des UTXOs dans votre portefeuille. -
Vérifiez que tout a fonctionné correctement :
bitcoin-cli getwalletinfo
-
Affichez les ordinals rares qui se trouvent dans votre portefeuille :
ord wallet sats
Exporter des descripteurs
Portefeuille Sparrow
Naviguez jusqu’à l’onglet Settings
, puis jusqu’à Script Policy
, et appuyez sur le bouton d’édition pour afficher le descripteur.
Transférer des ordinals
The ord
wallet supports transferring specific satoshis by using the name of the satoshi. To send the satoshi zonefruits
, do:
ord wallet send <RECEIVING_ADDRESS> zonefruits --fee-rate 21
You can also use the bitcoin-cli
commands createrawtransaction
, signrawtransactionwithwallet
, and sendrawtransaction
, but this method can be complex and is outside the scope of this guide.
Settings
ord
can be configured with the command line, environment variables, a configuration file, and default values.
The command line takes precedence over environment variables, which take precedence over the configuration file, which takes precedence over defaults.
The path to the configuration file can be given with --config <CONFIG_PATH>
. ord
will error if <CONFIG_PATH>
doesn't exist.
The path to a directory containing a configuration file name named ord.yaml
can be given with --config-dir <CONFIG_DIR_PATH>
or --datadir <DATA_DIR_PATH>
in which case the config path is <CONFIG_DIR_PATH>/ord.yaml
or <DATA_DIR_PATH>/ord.yaml
. It is not an error if it does not exist.
If none of --config
, --config-dir
, or --datadir
are given, and a file named ord.yaml
exists in the default data directory, it will be loaded.
For a setting named --setting-name
on the command line, the environment variable will be named ORD_SETTING_NAME
, and the config file field will be named setting_name
. For example, the data directory can be configured with --datadir
on the command line, the ORD_DATA_DIR
environment variable, or data_dir
in the config file.
See ord --help
for documentation of all the settings.
ord
's current configuration can be viewed as JSON with the ord settings
command.
Example Configuration
# example config
# see `ord --help` for setting documentation
bitcoin_data_dir: /var/lib/bitcoin
bitcoin_rpc_password: bar
bitcoin_rpc_url: https://localhost:8000
bitcoin_rpc_username: foo
chain: mainnet
commit_interval: 10000
config: /var/lib/ord/ord.yaml
config_dir: /var/lib/ord
cookie_file: /var/lib/bitcoin/.cookie
data_dir: /var/lib/ord
height_limit: 1000
hidden:
- 6fb976ab49dcec017f1e201e84395983204ae1a7c2abf7ced0a85d692e442799i0
- 703e5f7c49d82aab99e605af306b9a30e991e57d42f982908a962a81ac439832i0
index: /var/lib/ord/index.redb
index_addresses: true
index_cache_size: 1000000000
index_runes: true
index_sats: true
index_transactions: true
integration_test: true
no_index_inscriptions: true
server_password: bar
server_url: http://localhost:8888
server_username: foo
Hiding Inscription Content
Inscription content can be selectively prevented from being served by ord server
.
Unlike other settings, this can only be configured with the configuration file or environment variables.
To hide inscriptions with an environment variable:
export ORD_HIDDEN='6fb976ab49dcec017f1e201e84395983204ae1a7c2abf7ced0a85d692e442799i0 703e5f7c49d82aab99e605af306b9a30e991e57d42f982908a962a81ac439832i0'
Or with the configuration file:
hidden:
- 6fb976ab49dcec017f1e201e84395983204ae1a7c2abf7ced0a85d692e442799i0
- 703e5f7c49d82aab99e605af306b9a30e991e57d42f982908a962a81ac439832i0
Teleburning
Teleburn addresses can be used to burn assets on other blockchains, leaving behind in the smoking rubble a sort of forwarding address pointing to an inscription on Bitcoin.
Teleburning an asset means something like, "I'm out. Find me on Bitcoin."
Teleburn addresses are derived from inscription IDs. They have no corresponding private key, so assets sent to a teleburn address are burned. Currently, only Ethereum teleburn addresses are supported. Pull requests adding teleburn addresses for other chains are welcome.
Ethereum
Ethereum teleburn addresses are derived by taking the first 20 bytes of the SHA-256 hash of the inscription ID, serialized as 36 bytes, with the first 32 bytes containing the transaction ID, and the last four bytes containing big-endian inscription index, and interpreting it as an Ethereum address.
Exemple
The ENS domain name rodarmor.eth, was teleburned to inscription zero.
The inscription ID of inscription zero is 6fb976ab49dcec017f1e201e84395983204ae1a7c2abf7ced0a85d692e442799i0
.
Passing 6fb976ab49dcec017f1e201e84395983204ae1a7c2abf7ced0a85d692e442799i0
to the teleburn command:
$ ord teleburn 6fb976ab49dcec017f1e201e84395983204ae1a7c2abf7ced0a85d692e442799i0
Returns:
{
"ethereum": "0xe43A06530BdF8A4e067581f48Fae3b535559dA9e"
}
Indicating that 0xe43A06530BdF8A4e067581f48Fae3b535559dA9e
is the Ethereum teleburn address for inscription zero, which is, indeed, the current owner, on Ethereum, of rodarmor.eth
.
Tests
Test Environment
ord env <DIRECTORY>
creates a test environment in <DIRECTORY>
, spins up bitcoind
and ord server
instances, prints example commands for interacting with the test bitcoind
and ord server
instances, waits for CTRL-C
, and then shuts down bitcoind
and ord server
.
ord env
tries to use port 9000 for bitcoind
's RPC interface, and port 9001
for ord
's RPC interface, but will fall back to random unused ports.
Inside of the env directory, ord env
will write bitcoind
's configuration to bitcoin.conf
, ord
's configuration to ord.yaml
, and the env configuration to env.json
.
env.json
contains the commands needed to invoke bitcoin-cli
and ord wallet
, as well as the ports bitcoind
and ord server
are listening on.
These can be extracted into shell commands using jq
:
bitcoin=`jq -r '.bitcoin_cli_command | join(" ")' env/env.json`
$bitcoin listunspent
ord=`jq -r '.ord_wallet_command | join(" ")' env/env.json`
$ord outputs
If ord
is in the $PATH
and the env directory is env
, the bitcoin-cli
command will be:
bitcoin-cli -datadir=env
And the ord
will be:
ord --datadir env
Test Networks
Ord peut être testé en utilisant les drapeaux suivants pour spécifier le réseau de test. Pour plus d'informations sur l'exécution de Bitcoin Core en mode test, consultez la documentation pour développeurs de Bitcoin.
Most ord
commands in wallet and explorer can be run with the following network flags:
Réseau | Drapeau |
---|---|
Testnet | --testnet ou -t |
Signet | --signet ou -s |
Regtest | --regtest ou -r |
Regtest doesn't require downloading the blockchain since you create your own private blockchain, so indexing ord
is almost instantaneous.
Exemple
Run bitcoind
in regtest with:
bitcoind -regtest -txindex
Run ord server
in regtest with:
ord --regtest server
Créez un portefeuille sur regtest avec :
ord --regtest wallet create
Obtenez une adresse de réception sur regtest avec :
ord --regtest wallet receive
Minez 101 blocs (pour débloquer la récompense du coinbase) avec :
bitcoin-cli -regtest generatetoaddress 101 <receive address>
Inscrivez sur regtest avec :
ord --regtest wallet inscribe --fee-rate 1 --file <file>
Minez l’inscription avec :
bitcoin-cli -regtest generatetoaddress 1 <receive address>
By default, browsers don't support compression over HTTP. To test compressed content over HTTP, use the --decompress
flag:
ord --regtest server --decompress
Test de récursion
Lorsque vous testez la récursion, inscrivez d'abord les dépendances (exemple avec p5.js) :
ord --regtest wallet inscribe --fee-rate 1 --file p5.js
This will return the inscription ID of the dependency which you can then reference in your inscription.
However, inscription IDs differ between mainnet and test chains, so you must change the inscription IDs in your inscription to the mainnet inscription IDs of your dependencies before making the final inscription on mainnet.
Ensuite, vous pouvez inscrire votre inscription récursive avec :
ord --regtest wallet inscribe --fee-rate 1 --file recursive-inscription.html
Enfin, vous devrez miner quelques blocs et démarrer le serveur :
bitcoin-cli generatetoaddress 6 <receive address>
Mainnet Dependencies
To avoid having to change dependency inscription IDs to mainnet inscription IDs, you may utilize a content proxy when testing. ord server
accepts a --proxy
option, which takes the URL of a another ord server
instance. When making a request to /content/<INSCRIPTION_ID>
when a content proxy is set and the inscription is not found, ord server
will forward the request to the content proxy. This allows you to run a test ord server
instance with a mainnet content proxy. You can then use mainnet inscription IDs in your test inscription, which will then return the content of the mainnet inscriptions.
ord --regtest server --proxy https://ordinals.com
Conseils pour la chasse aux récompenses d’Ordinals
-
Le portefeuille
ord
peut envoyer et recevoir des satoshis spécifiques. De plus, la théorie ordinale est extrêmement simple. Un hacker ingénieux devrait être capable d'écrire du code à partir de zéro pour manipuler des satoshis en utilisant la théorie ordinale en un rien de temps. -
Pour plus d'informations sur la théorie ordinale, consultez la section FAQ pour une vue d'ensemble, le BIP pour les détails techniques, et le référentiel ord pour le portefeuille
ord
et l'explorateur de blocs. -
Satoshi a été le premier à développer la théorie ordinale. Cependant, il savait que d'autres la considéreraient comme hérétique et dangereuse, il a donc dissimulé ses connaissances, qui ont fini par disparaître avec le temps. Ce n’est que maintenant que cette théorie puissante est redécouverte. Vous pouvez y contribuer en recherchant des satoshis rares.
Bonne chance et que la réussite vous accompagne !
Récompense Ordinal 0
Critères
Envoyez un sat dont le nombre ordinal se termine par un zéro à l'adresse de soumission :
Le sat doit être le premier sat de la sortie que vous envoyez.
Récompense
100,000 sats
Adresse de soumission
1PE7u4wbDP2RqfKN6geD1bG57v9Gj9FXm3
État
Réclamé par @count_null !
Récompense Ordinal 1
Critères
La transaction qui soumet un UTXO contenant le sat le plus ancien, c'est-à-dire celui avec le numéro le plus bas parmi tous les UTXOs soumis, sera jugée gagnant.
L'appel à candidatures pour la récompense restera ouvert jusqu'au bloc 753984, le premier bloc de la période d'ajustement de la difficulté 374. Les candidatures soumises à partir du bloc 753984 ou ultérieurement ne seront pas prises en compte.
Récompense
200 000 sats
Adresse de soumission
145Z7PFHyVrwiMWwEcUmDgFbmUbQSU9aap
État
Réclamé par @ordinalsindex !
Récompense Ordinal 2
Critères
Send an uncommon sat to the submission address:
Confirmez que l'adresse de soumission n'a pas reçu de transactions avant de soumettre votre candidature. Seule la première soumission réussie sera récompensée.
Récompense
300 000 sats
Adresse de soumission
1Hyr94uypwWq5CQffaXHvwUMEyBPp3TUZH
État
Réclamé par @utxoset !
Récompense Ordinal 3
Critères
La récompense Ordinal 3 se compose de deux parties, toutes deux basées sur les noms ordinaux. Les noms ordinaux sont un encodage en base-26 modifié des nombres ordinaux. Pour éviter que les noms courts restent piégés à l'intérieur du bloc de genèse et ne puissent pas être utilisés, les noms ordinaux deviennent plus courts à mesure que le nombre ordinal devient plus long. Le nom du sat 0, le premier sat à être miné, est nvtdijuwxlp
et le nom du sat 2,099,999,997,689,999, le dernier sat qui sera miné, est a
.
The bounty is open for submissions until block 840000—the first block after the fourth halving. Submissions included in block 840000 or later will not be considered.
Les deux parties utilisent frequency.tsv, une liste de mots et le nombre de fois qu'ils apparaissent dans l'ensemble de données Google Books Ngram. Ce fichier a été filtré pour n'inclure que les noms des sats qui auront été minés à la fin de la période de soumission et qui apparaissent au moins 5 000 fois dans le corpus.
frequency.tsv
est un fichier de valeurs séparées par des tabulations. La première colonne est le mot, et la seconde le nombre de fois qu'il apparaît dans le corpus. Les données sont organisées de manière à ce que les mots les moins fréquents apparaissent en premier, suivis des mots les plus fréquents.
frequency.tsv
a été compilé à l'aide de ce programme.
Pour rechercher des sats dans un portefeuille ord
dont le nom figure dans frequency.tsv
, utilisez la commande ord
suivante :
ord wallet sats --tsv frequency.tsv
Cette commande nécessite l'index sat, vous devez donc inclure le paramètre --index-sats
dans ord lorsque vous créez l'index pour la première fois.
Partie 0
Les sats rares s'associent mieux aux mots rares.
La transaction qui soumet l'UTXO contenant le sat dont le nom apparaît avec le plus petit nombre d'occurrences dans frequency.tsv
sera le gagnant de la partie 0.
Partie 1
Popularity is the fount of value.
La transaction qui soumet l'UTXO contenant le sat dont le nom apparaît avec le plus grand nombre d'occurrences dans frequency.tsv
sera le gagnant de la partie 1.
Critères de départage
En cas d'égalité, lorsque deux soumissions surviennent avec la même fréquence, la soumission effectuée en premier sera déclarée gagnante.
Récompense
- Partie 0 : 200 000 sats
- Partie 1 : 200 000 sats
- Total : 400 000 sats
Adresse de soumission
17m5rvMpi78zG8RUpCRd6NWWMJtWmu65kg
État
Pas réclamé !