Completed: BNT-9 - Ordinals Canister


Status: Completed
Project Type: Cooperative/Contest - Multiple workers can submit work and the bounty is shared
Time Commitment: Days
Experience Level: Beginner - Intermediate
Size: USD 3’000 in ICP (at time of distribution)
Deadline: -


The current Bitcoin Canister on the Internet Computer only stores the set of unspent transaction outputs (UTXOs). This is not enough information to find out:

  • which ordinals are inside a given UTXO
  • to what level of rarety they belong
  • if they have an associated inscription

Until we have all this information on the Internet Computer, we want to encourage building a sustainable Open Internet Service that allows fetching this information from third-party indexing services using HTTPS outcalls.


  • Given a UTXO return a list of ordinal (ranges)
  • Given an ordinal return the rarety and inscription (if available)
  • Calls to the canister should require cycles to cover the cycles cost of the canister to make it sustainable (similar to the Bitcoin canister itself, or the Exchange Rate Canister)

Acceptance Criteria

  • Open Internet Service deployed to the Internet Computer
  • Proper Readme, see here
  • Video Pitch/Demo (max. 4min)
  • Open Source license (MIT or Apache-2.0)

Evaluation Criteria

  • Functionality
  • Code quality


There are many APIs that can provide ordinal information. One current prerequisite of the API is that it has to support an IPv6 connection.

How to participate?

Post your submission in this thread.
Please be aware that Terms and Conditions of the DFINITY Developer Grants Program apply.



Thanks for posting this BNT.

AstroX loves to take the challenge, and I will update this post later with details

1 Like

@neeboo What is the status of the project?
I wouldn’t mind jumping in.

1 Like

Hi @sadernalwis

The work has just started. We have progressive plan like this:

  1. Similar to ICP<>ETH integration plan, we should quickly port usable Ordinals APIs to canister using Http Outcalls.
    Hiro’s API looks nice, docs and usable codes are there. Wouldn’t take too long to complete.

Guys from Hiro use ordhook/chainhook to index Ordinals Data and use nodejs(Cloudflare) to serve the APIs. We can complete the task quickly because:

  • The RESTFUL apis are openAPI 3.x compatible, it wouldn’t be hard to generate usable rust code with types.
  • We can use standard candid function to serve similar API to the nodejs one.
  • We can contact with Hiro to get a usable API key, but we should carefully design the cache strategy to prevent we hit the limit during outcalls.

And then we can build a POC canister to serve API to IC ecosystem.

  1. The on-chain indexer is the next step, and it is very similar to ICP<>BTC integration. We should consider a few things to be done.
  • To build a Ordinals Canister similar to Ord. Since we are only interested in indexing the data, we just replace the redb to canister stable structure.
  • Still, we can learn from Hiro’s Ordhook to make the work easier.
  • Last but not least, replace the outcall API to canister native API, then we can keep iterating and get more things done, for example BRC20 canister and more.

I should update this thread to keep this going. Also we are looking forward to participating the IC Bitcoin working group to discuss more.


@neeboo/@sadernalwis any updates on this?

@domwoe Oh sorry. I also forgot to reply to @neeboo .

@neeboo seems like you were already a few days away from submitting. And wish you good luck.

@domwoe since @neeboo seems to have closed in on this I did not try to take a separate attempt.

However since it was important to my current project, I did start an alternative approach for ordinals verification without using http_outcalls.

We were planning to update u.

Let me know if it’s the right time and place.


Hi @domwoe,

I’d like to submit my work for the Ordinals canister, the project is here.

I made [a short presentation]( IC ordinals canister - YouTube) as requested, sorry the mic quality is not great.

If I may ask, I’d like to have your feedback on the function that computes the cost of the request. I pretty much used the one from the EVM RPC canister, but used the numbers found in the specs:

/// Cycles cost constants, based on
pub const INGRESS_OVERHEAD_BYTES: u128 = 100;
pub const INGRESS_MESSAGE_RECEIVED_COST: u128 = 1_200_000;
pub const HTTP_OUTCALL_REQUEST_COST: u128 = 49_140_000; // TODO: Double check (in the eth-rpc project, it is set to 400_000_000)
pub const HTTP_OUTCALL_BYTE_RECEIVED_COST: u128 = 10_400; // TODO: Double check (in the eth-rpc project, it is set to 100_000)

pub fn get_http_request_cost(
    api: &RpcApi,
    payload_size_bytes: u64,
    max_response_bytes: u64,
) -> u128 {
    let ingress_bytes = payload_size_bytes as u128 + url.len() as u128 + INGRESS_OVERHEAD_BYTES;
        + INGRESS_MESSAGE_BYTE_RECEIVED_COST * ingress_bytes
        + HTTP_OUTCALL_BYTE_RECEIVED_COST * (ingress_bytes + max_response_bytes as u128);
    base_cost as u128

Are the base numbers different in the EVM-RPC canister from what is written in the spec to make the canister profitable? In mycomputation, should I not also add the cost of each message byte multiplied by the “HTTPS outcall request message size (per byte)”?

Thank you!

1 Like

Thank you for the submission!

Could it be that you still need to make the repo public? I get a 404.
Have you tested the project on mainnet as well?

I’d agree with your reasoning about the costs, but maybe @rvanasa can explain the parameters chosen in the EVM RPC canister.

My bad, I just made the repo public, it should work now.

Yes I tested on the IC too, the deployed canister is here.

Thanks for reaching out about this! You should be okay using the numbers in the spec; the EVM RPC canister uses values prior to the HTTP outcall cost reduction, so that will likely change before the official release.

1 Like

It`s finish? it style open of grants issue 44