Protocol Specification

Ordinals-compatible, built on Bitcoin SV
Protocol: 1Sat Ordinals
Status: DRAFT


1SatOrdinals in an implementation of Ordinals running on the BSV blockchain.
See the Ordinals Docs for more information on Ordinals and ordinal theory.
This inscription script represents an inscription on an ordinal. The output value is 1 satoshi.
OP_FALSE OP_IF 6f7264 OP_1 <content-type> OP_0 <data> OP_ENDIF
A locking script (typically P2PKH) is then appended to the inscription script seperated by OP_CODE_SEPERATOR.
<inscription script> OP_CODE_SEPERATOR <locking script>
Note: OP_CODE_SEPERATOR is not strictly required for an inscription to be valid, but should be used with P2PKH for compatiblity across wallets.

Creating an Inscription

Creating an inscription requires a single transaction. To summarize the transaction template:
Input #1 - Any valid utxo
Output #1 - Inscription w/ Locking Script (1 Satoshi)
Output #2 - Change
The output with this script should lock exactly 1 Sat.

ord Envelope

Inscribe a data file by filling in the two inscription fields, data and content-type.
OP_FALSE OP_IF "ord" OP_1 <content-type> OP_0 <data> OP_ENDIF

Locking Script

Typically, a P2PKH script is used to lock the ordinal. Simply send the 1 sat output to a new destination to transfer it. From here on, 1SAT_P2PKH refers to a standard p2pkh output with a single sat value, but keep in mind, any locking script can be used.


To transfer ownership, simply send the 1sat output to the intended recipient as you normally would with any utxo while maintaining ordinality of the satoshi being transferred. (i.e. the nth satoshi input to the transaction is transferred to the nth satoshi output of the transaction)
i1 - 1sat_p2pkh
i2 - funding utxo
o1 - 1sat_p2pkh
o2 - change
You can also append to the inscriptions on an ordinal by inscribing the same sat again.
i1 - previously inscribed ordinal
i2 - funding utxo
o1 - second inscription w/ 1sat_p2pkh
o2 - change


In this example, we inscribe a 3d model (GLTF binary) and tag it with a geolocation:
Mint & Inscribe: (1SAT_P2PKH + inscription)

Ordinals vs 1SatOrdinals

The BSV blockchain is unique among blockchains which support ordinals, in that BSV supports single satoshi outputs. This allows us to take some short-cuts in indexing efficiently. We call this origin-based indexing.
Since ordinals are a unique serial number for each satoshi, an origin can be defined as the first outpoint where a satoshi exists alone, in a one satoshi output. Each subsequent spend of that satoshi will be crawled back only to the first ancestor is an output which contains more than one satoshi.
If a satoshi is subsequently packaged up in an output of more than one satoshi, the origin is no longer carried forward and the token can be considered burned. If the satoshi is later spent into another one satoshi output, a new origin will be created. Both of these origins would be the same ordinal, but are distinct tokens in 1SatOrdinals.
1SatOrdinals uses the same inscription rules as the founding implementation on BTC, with the following caveats/clarifications:

Inscribing in Outputs

Due to the use of Tap Root in BTC, inscriptions are exposed in the input scripts. On BSV, they are written in outputs. Due to this difference, Inscription IDs in 1SatOrdinals are stated in relation to the output of a transaction, and take the form of <txid hex>_<vout>.

1 Satoshi Outputs

1SatOrinals requires inscrptions to be made on a single satoshi output.


On BSV, push data are NOT limited to 520 bytes and values should NOT be concatenated across multiple data pushes.

Valid Inscriptions

An inscription is considered valid if an ord envelope is present inline in an output script on a 1 satoshi output.

ord Envelope Format

<field1> <value1>
<fieldN> <valueN>
OP_0 <content>
  • field and value MUST alway appear as pairs
  • field MUST be a single PUSH_DATA or OP_1-OP_16
  • value MUST be a single PUSH_DATA, OP_0, or OP_1-OP_16
See the Ordinals Docs for more information on Ordinals fields.

Field Aliases

Due to ambiguity of documentation and implementations of Bitcoin ASM, OP_1-OP_16 are treated as alieses of the corisponding push values of OP_DATA_1 followed by the value 1-16

Repeated Fields

Parsing considerations for handling if a field is repeated is not defined in the Ordinals Spec. 1SatOrdinals treats repeated fields such that later values will overwrite previous values.


1SatOrdinals is a superset of the Ordinals Protocol and is 100% backward compatible.
We take a different approach to indexing due to the expanded capacity of the BSV blockchain. origin indexing is built on the idea that it ultimately doesn't matter WHICH specific ordinal is being transferred across the blockchain, as long as it can be easily determined that multiple transactions are referencing the SAME ordinal.
origins are tracked within the 1SatOrdinals indexer only as 1-satoshi outputs. If you inscribe on more than 1 satoshi, that the inscription is not a valid 1SatOrdinal.


Last modified 2mo ago