BNT-15 Runes Launchpad

Status: Complete
Project Type: Cooperative/Contest - Multiple workers can submit work and the bounty is shared
Time Commitment: Days
Experience Level: Intermediate
Size: Up to USD 10’000 in ICP (at time of distribution) - Up to 5k per worker.
Deadline: Extended (TBD)


Runes are a new protocol to create and transfer fungible tokens on Bitcoin. The protocol was designed by Caset Rodamor, the inventor of Ordinals, to be more efficient than prior popular meta protocols like BRC-20. Runes protocol messages are stored in OP_RETURN transaction outputs and thus don’t lead to the bloat of the UTXO set, i.e. of the Bitcoin state.

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.

In this bounty, your task is to create an etching or launchpad service inside a canister.

Acceptance Criteria

  • Frontend and backend implemented on ICP
  • Option to connect/pay with Bitcoin Wallet or with ckBTC
  • Uses threshold ECDSA and Bitcoin API
  • Allows to set parameters according to spec
  • Open source code under MIT or Apache-2.0 license on Github
  • Proper README
  • Short Video Demonstration

Evaluation Criteria

  • Design/UX
  • Functionality
  • Code quality

Potential Followons

  • Create a wrapped version of Runes and use liquidity bootstrapping, i.e. bonding curve to sell the pre-mine allocation and establish a price

How to participate?

Post your submission here in the thread. Please introduce yourself early on if you plan to participate.
Please be aware that Terms and Conditions of the DFINITY Developer Grants Program apply.



The original deadline passed yesterday. Is anyone working on this bounty?

hello @domwoe

I’m working on it, here is my code so far: etcher


Would you mind making the code public?

We’ll extend the deadline. I’ll give an update in the next couple of days.

1 Like

I’ve made the code public!

1 Like


here is the missing thing:

  • Conversion of name into base26 number.
    I had problem understanding how it works. As the docs said: A is 0, B is 1, … and BA is 52. I wasn’t able to figure out how BA would be 52. It took 2 days to understand this😅
  • Test using the CKBTC as payment option. I wasn’t able to build n deploy CKBTC minter locally.
    Here is my flow, that I’m thinking to achieve.

Also the last thing,
I wasn’t able to find any testnet faucet with good balance.

1 Like


Here’s the Rune launcher repo

It works, its tested and trusted

1 Like

Hello there, I want to note that the runes now only support taproot addresses currently, and it needs to be signed with schnnor signature. But now the ICP only supports t-ecdsa signature.(For the wpkh address)
For the runes, we need a commit transaction and reveal transaction, so we need a reveal script which needs to insert tapscript to the reveal transaction.
So we need a lot of work to do. :slight_smile:

1 Like

Yep, this is true. There are a couple of workarounds though, for example:

1 Like

@icnerd @Zedonboy

We are planning to extend the deadline until Sunday. Would that work for you?

Please make sure that you meet all the points in the acceptance criteria until the deadline.


You can also immediately transfer any premined tokens to a PWSH address.
Do you mean we can use Schnnor key in the canister to sign the segwit v1 transaction with a p2wsh address and send the transaction to bitcoin network?(If we send the transaction from ICP to bitcoin network, can we track it in the mempool or blocksteam?)

This needs to be verified by someone looking into the spec in detail, but I assume you can essentially allocate the runes to a normal PSWH output already with the reveal transactions. If that’s not possible you’d need one additional transaction.

Yes, sure. These are all regular Bitcoin transactions that get submitted to the Bitcoin network.

hello @cymqqqq , didn’t knew there were such specifications for rune, could you share the link/resources to learn more about these?
in the rune’s documentation, I didn’t see any such things being mentioned.

I would like to learn more about this!

From the Specification: Specification - Ordinal Theory Handbook

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.

To fulfill this bounty, we expect a demo that shows the runes showing up in the ord indexer.

You can not find it in the rune’s documentation, because it doesn’t exist in the doc, and there are a lot of details that you need to read the source code and I can not post here(very complicated). I have read all of the rune source code since last year, so I know a lot of fundamentals about how to etch runes, how to mint runes, how to build commit transactions, how to build reveal transactions, and so on. So if you want to know more things about the runes, you can go to the rune source code.

Personally, I think it’s difficult to implement the demo now because the runes source code is still under development. And if we want to do this, we need to write a lot of infra code to build Bitcoin transactions.

I’d be really curious to see the code which shows that currently only P2TR outputs would be considered in the Runes protocol.

If that indeed be the case, we could change the bounty to use the schnorr canister.

For reference, here’s a project that uses quite a bit of code from ord to inscribe ordinals using (an outdated version of) the schnorr canister and sends it to P2PKH address controlled by a canister: GitHub - domwoe/inscription_canister: Ordinal Inscription Testbed on ICP.

I have read the bitcoin_wallet module in this repo, so there is a commit transaction and a reveal transaction signed by schnnor key that is used to build an inscription transaction, and a p2pkh transaction signed by t-ecdsa key.
For the rune protocol, we need to bind each rune with a native utxo(Not an address), it is based on inscription but different from inscription. First, you need an outpoint with the satoshi on your address, then you inscribe an inscription. Next step, you etch a rune based on your inscription id. then you mint a rune with one of your outpoints. Like this:

Now I’m building a native bitcoin asset protocol based ICP network, and it can use ICP bitcoin light node to update utxo set, and I will opensource it later, I also want this bounty but maybe it’s not the right time for me. :slight_smile:
I advise the Dfinity Team can develop an interface that can fetch raw transactions from bitcoin network by txid(transaction hash), it will help us do a lot of things.

I agree that this would be useful but it’s also not strictly necessary. The first step that is being worked on is to make block headers available via the Bitcoin API, see Adding an endpoint to fetch bitcoin block headers by THLO · Pull Request #298 · dfinity/interface-spec · GitHub.

You can fetch raw transactions (+ merkle proofs) from an untrusted source and verify that they are indeed part of the Bitcoin blockchain. If you’re interested in building such a utility canister, please apply for a grant. But this discussion is not necessary for this bounty/thread.

ICP Rune Launch Pad Submission
Repo: GitHub - Zedonboy/icp_rune_launcher