Ordinal Envelopes

An ordinal envelope is a mechanism that allows Counterparty assets to be moved into and out of an individual satoshi via its Ordinal number.

From a technical perspective, this implementation is fairly straightforward. The challenge is convincing the Counterparty community that the rewards of integrating ord outweigh the potential risk to long term stability of the platform.

I’m writing this post to eventually publish as a CIP so will keep the same format for portability…


Ordinal numbers are serial numbers for satoshis, assigned in the order in which they are mined, and preserved across transactions. They are described in Bitcoin BIP pr1408 and implemented with ord.

By integrating Ordinal numbers into the Counterparty federated node stack, they can be viewed through the lens of Counterparty’s account model as one-time use addresses.

This proposal covers at least one method for integration and starts the discussion of how Counterparty could view ord within the bitcoin ecosystem.


Ordinal theory is similar to Counterparty in terms of platform consensus. They are both smart contracts deployed as node software rather than as on-chain logic (EVM). Users subscribe to the rules because it ensures all tokens are interoperable within the platform. Connecting the Ordinal and Counterparty ecosystems is prudent for increasing interoperability within the broader bitcoin ecosystem.


Counterparty in its current state is not able to utilize the benefits of Bitcoin’s utxo model. By storing message information within a Bitcoin transaction it abstracts the transaction rules to the Counterparty layer. Storing assets within ordinal envelopes also gives Counterparty users the option to use their assets within the Ordinal ecosystem.

Important to note that when bridging the two platforms via the ordinal envelopes scheme, Ordinal software does not need to be Counterparty aware in the same way Bitcoin software is not Counterparty aware.


Ordinal envelopes are one-time use addresses that can be thought of as a sort of on-chain Opendime for assets. While an Opendime requires a user to destroy a physical device to send the contents, ordinal envelopes require a user to destroy a satoshi to send its contents. Once destroyed the Counterparty assets either complete their roundtrip journey back to the Counterparty platform or they’re sent to another envelope.

Ordinal envelopes as an address type

Counterparty interprets bitcoin addresses as account numbers. With the addition of enhanced sends (CIP9), addresses have been defined within the send message data rather than through the use of a dust output which allows for any arbitrary address scheme. Address type is identified by the first byte in the parameter.

Ordinal envelope addresses can be defined by the unique first byte ff followed by the ordinal number, ex. 2099994106992699. Envelope addresses are stored in the existing balances table in counterparty-lib. Assets can then be sent to envelope addresses using the existing enhanced send message type.

Emptying an envelope

While sending assets to an envelope does not require an additional message type, emptying an envelope does. The emptying tx requires rendering the envelope satoshi unspendable by adding it to the OP_RETURN output that contains the emptying tx message data (which includes the receiving address). Counterparty-lib can validate an emptying tx by identifying the ordinal number of the satoshi sent to the OP_RETURN output and searching for it in the balances table. All asset balances held by the envelope address are then transferred to the output address defined in the emptying tx message data.



API Changes





This is good to see! XCP wallets should support Ord and vanilla inscribe func and this proposal seems ideal way to get the two protocols cohesive.

spot on with the motivation joe, keep up the good work. incorporating ordinals and making it easier for the current Counterparty user base seems like a solid use of time and resources to consider this concept

Nice to see the CounterParty community pay attention to Ordinals, which solve a few things about asset creation within Bitcoin. I do have some doubts regarding this proposal: is it really necessary to do an “envelope” thing, much like EmblemVault with Ethereum? or can Ordinals be truly integrated into CounterParty? so assets live directly in Bitcoin without the need to “unwrap” and burn satoshis with each transaction.

Just as an example of potential consequences, take these NFT daily transfer stats, over 500k happen daily on Ethereum: Daily # of Ethereum NFT Transfers

If this NFT thing really catches on on Bitcoin, there could be some serious money burning, making it dangerous and an argument for inflationist, like Peter Todd, to add infinite inflation to the Bitcoin protocol.