CIP 26 - STAMP Protocol

A few weeks ago @mikeinspace posted a document outlining how users could “stamp” an image to a token, and also laid out the basic guidelines and rules for the “Bitcoin Stamps” project. This project has seen a bunch of attention lately, over 32k+ items have been “stamped” to tokens on Counterparty, and people are even “stamping” over on Dogeparty. Also “Bitcoin Stamps” has resulted in a bunch of new users and developers interested in learning more about Counterparty. We all owe @mikeinspace a thank you for coming up with this “stamp” process and generating a bunch of new eyes on Counterparty.

Here is the Bitcoin Stamps Document to which I refer:

The purpose of this post, and the forthcoming “STAMP Protocol” CIP I am currently writing is to clarify the technical process of how to “stamp” a token with a file, separate it from any project-specific rules (numerics only, stamp must use multisig outputs, stamp must live in utxos, etc.)

I will post a link to the STAMP Protocol CIP pull request shortly.

1 Like

Here is the proposed “STAMP Protocol” CIP

and here is the pull request if anyone wants to comment on github directly

1 Like

First of all I want to thank JDog for being so supportive of Stamps from the beginning. Honestly, native xchain support was probably integral to Stamps’ success, in my view.

Regarding titles, I’ve heard back from many in the community that its something they would love to have and I think it can be implemented in a very non-invasive way.

Following the method employed by xchain already for imgur and youtube links:

imgur/i08zbUH.png; Title Goes Here

Method for Stamps: stamp:iVBORw0KGgoAAAANSUhEUg==; Title Goes Here

We are also thinking through a method of adding titles to older stamps without requiring users to touch the asset description again. We believe this can be facilitated through a broadcast-type txn that references the asset name and the title. Formatting has not yet been finalized but something along these lines:

STAMP_TITLE:A9364494683859804778 = This is the title

It would be valid if broadcast from the issuance address of the asset.

STAMP_TITLE:A9364494683859804778 = This is the title

I was thinking about this the other day too.
Broadcasts standardized for STAMPS is a clean approach for various purposes imo.

I might suggest this format:


And this sort of namespaced message prefix can be used for other things such as messaging your community or individual owner.


Messages can appear with STAMPS in marketplaces/wallets.

Or perhaps


A way to share official links related to project/artist etc.

After giving this “TITLE” topic a bit more thought… I feel that the “STAMP Protocol” should remain clean and only pertain to stamping files to the blockchain, and not be modified to fit in this “title” field.

If someone wants to include additional information about a STAMP, I think the most straightforward approach would be to stamp a second JSON file which contains additional information about the stamp. This will allow for inclusion of a bunch of additional information about a stamp, in a file format that is open… and maintains the “stamps only deal with files” rule (which is necessary to implement the next forthcoming “STAMP Filesystem” CIP, where stamps are compartmentalized and stamp data is removed from the CP/sqlite database and written to actual files)

Example JSON
{ "title": "This is a really long title for this artwork" }

IMAGE encoded into a STAMP file

JSON encoded into a STAMP file

IMAGE and JSON Stamp

As far as the “Stamp Title via Broadcast” method, I have no objections to this method, as it is completely external from the STAMP protocol.