IC Roadmap Milestones for 2022 (Sneak Preview)

Ahoy IC devs!

It brings us great joy to present DFINITY’s roadmap for its contributions to the IC: a basket of features and improvements over the next few months. Most of these (as you will see) came from NNS proposals or forum conversations, so your engagement in direction of IC has been a key role in its development.

TLDR: Next 2 months are DeFi-heavy.


One of the most common requests from the IC Community is a roadmap to help layout in a linear, easy-to-understand fashion the releases and timeline of features, optimizations, and improvements to the Internet Computer from the DFINITY Foundation.

In fact, this is how releases were done pre-Genesis (See the 5 previous releases from 2020 to 2021), but after Genesis Q2 2021, the DFINITY team focused on the realities and surprises of a nascent blockchain. As they say, "the plans made contact with reality", so improvements were a combination of community-driven proposals and network needs.

Now in 2022, the DFINITY Foundation is going back to its roots.

Over the next few weeks, the DFINITY Foundation is releasing official roadmaps for different milestones. The first two are Titanium (mid Q1 2022) and Chromium (end of Q1). Subsequent updates for Carbon (Q2 2022), Vanadium (Q3 2022), and Iridium (Q4 2022) are incoming.

This forum post is an early preview to our amazing developer community, as a user-friendly website for the wider IC community is will be launched soon.

Titanium - mid Q1

Goal of Titanium: DeFi pre-releases

1. Titanium Example Dapps

Conversation Lead: @samuelburri
Example dapps will illustrate key features of the IC shall help IC developers to kick start their project. Every example dapp comes with an implementation in Motoko and Rust. The examples include (1) NFT creation, management and selling; (2) a very basic DAO; (3) a simple DEX; and (4) encrypted notes demonstrating how to achieve confidentiality on the IC.

  • Proposal link: none
  • Forum link: none

2. Bitcoin Integration Developer Preview

Conversation Lead: @dieter.sommer

The Internet Computer will be integrated with the Bitcoin blockchain network in the upcoming Chromium release. The API of this feature will be made available as a Developer Preview release that can be used in the local development environment. The IC mainnet integration will not yet be available with this release. The goals of this preview are to give smart contract developers the ability to use the API in their local development environment and to solicit feedback from our developer community to be considered for the main release.

3. Merge Neurons

Conversaton Lead: @jwiegley

Permit the merging of multiple neurons owned by the same controller key into a single neuron. This is implemented by transferring all stake, age, and maturity from a source neuron into a target neuron, provided the necessary preconditions are met. The properties of the resulting neuron are derived from those of all the source neuron by weighting them according to their respective stake.

  • Proposal link: none
  • Forum link: none

4. Simple APIs for Ledger Transactions

Conversation Lead: @bogwar @kpeacock

We will develop an invoicing canister that will implement familiar concepts around invoices (creation, payment, querying) while abstracting away the particularities of the ICP ledger canister. This will enable simple, easy to integrate, pay-for-service flows between Internet Computer principals.

5. Ledger Canister Fit for Dapps

Conversation Lead: @bogwar

We will provide and maintain a ledger canister as a building block for developers to easily deploy custom tokens on the Internet Computer, e.g., to tokenize dapps. The canister will benefit from the features of the ICP ledger, in particular, storage scalability via archive nodes and a compatible Rosetta node for easy integration with exchanges.

6. People Parties for Validating Personhood

Conversation Lead: @bjoern

Virtual people parties are a scalable proof of personhood, in which randomly assigned groups of users to validate each other through interaction. Validation of personhood improves decentralization on the Internet Computer by providing greater voting power and thus rewards to validated users, i.e., real people as opposed to unknown entities. Users can also present the proof of personhood toward dapps, which in turn can provide the users with greater privileges and rewards.

7. Verify Candid and Motoko Stable Variable Type Safety of Canister Upgrades

Conversation Lead: @claudio

Upgrading a canister can be difficult and cause disruption. It can break existing clients due to an incompatible Candid interface change and discard Motoko stable state due to an incompatible change in Motoko stable declarations. Both Candid interface compatibility and Motoko stable variable compatibility are relations that can be statically checked using canister metadata. We will provide tooling to verify these properties before attempting a canister upgrade. To support this feature, dfx requires exposing canister metadata, such as the Candid interface from the Wasm module. This and other metadata will be exposed via the Internet Computer state tree to allow users and tools to access metadata in a certified manner.

8. Enable Canisters to Hold ICPs

Conversation Leads: @roman-kashitsyn

This is complete, but improvements will continue to support defi.

9. NNS Managed Node Provider Remuneration

Conversation Leads: @bjoern @Luis

The NNS will transparently compute the rewards paid to each node provider based on the number of nodes owned, the nodes’ hardware specifications, and their location. This new mechanism replaces the prior method in which each node provider’s reward was specified via a proposal to the governance system.

Chromium - End of Q1

Goal: DeFi enablement

1. ICOS Boundary Nodes

Conversation Lead: Rudiger Kapitza

Today, the installation and configuration of boundary nodes requires manual intervention by the foundation’s employees. This feature establishes a fully-automated build process to facilitate improved automated testing and deployment and thereby enables NNS-driven deployment of boundary nodes. The operating system, IC OS, currently used for replica nodes, shall also be used for boundary nodes. This solution builds the basis for ongoing decentralization efforts.

2. Threshold ECDSA signatures: System Integration

Conversation Lead: @JensGroth

3. Threshold ECDSA signatures

Conversation Lead: @JensGroth

Done (already on today’s roadmap – one item for ECDSA should be sufficient)

4. Nodes Can be Reassigned to a Different Subnet

Conversation Lead: @gregory

Currently, the only way to reassign a node from one subnet to another is by redeploying the node from scratch, a tedious and error-prone process. This feature will allow nodes to be reassigned to other subnets through simple NNS proposals. Nodes will leave their old subnet “gracefully”, meaning, without having to count the departing node to the budget of faulty/malicious nodes in the subnet.

  • Proposal link: none
  • Forum link: none

5. Decentralized Node Addition

Conversation Lead: @yvonneanne

This feature allows node providers to set up and manage their nodes independently and automates the on-boarding of new node providers. This requires additional functionality in the NNS front-end dapp as well as their counterparts in the governance and registry canisters complemented by a deployment process and runbooks for node operation.

6. Enable HTTP Requests from Canisters

Conversation Lead: @yotam @dieter.sommer

This feature enables canister (dapps/smart contracts) on the Internet Computer to make HTTP(S) requests to services outside the IC and thus integrates the Internet Computer with the Web 2.0 world. This enables a plurality of new use cases, e.g., directly obtaining exchange rate data from external servers for DeFi dapps, obtaining weather data for decentralized insurance services, or sending notifications to end-users via traditional communications channels. The first version of this feature will cover a subset of the typical oracle service functionalities but will do so in a trustless manner, i.e., without making any additional trust assumptions.

7. Network Performance with Larger Network: State Sync, Certification, and XNet

Conversation Lead: @derlerd-dfinity1

This feature ensures that the Internet Computer meets future scalability requirements in terms of number of subnets and the size of their growing canister state. The main focus is on the scalability of the XNet communication protocol and the state sync protocol, including state certification.

8. Bitcoin Integration to Enable Bitcoin Smart Contracts

Conversation Lead: @dieter.sommer

Bitcoin, the world’s first blockchain, has evolved to the world’s digital store of value and is therefore often referred to as a digital version of gold. We directly integrate the Internet Computer with the Bitcoin blockchain, i.e., canisters can themselves hold and transfer bitcoin. Importantly, direct integration means that no additional trust assumptions are required and indeed no additional parties, such as bridges, are needed. This feature relies on threshold ECDSA signatures that make it possible for a subnet to sign on behalf of a canister with a secret-shared key. This feature will enable for the first time smart contracts for Bitcoin leveraging the countless powerful features of canisters.

9. Open Governance for Internet Services

Conversation Lead: @lara

Service nervous systems (SNSs) are algorithmic DAOs that will allow developers to create decentralized, token-based governance for their dapps.
First, this feature implements the governance canister for the service nervous systems. It is similar to the Network Nervous System (NNS)’s governance canister but has a simpler and more flexible design, allowing each SNS community to choose the configurations according to their needs.
Second, this feature provides support for the deployment and upgrade of SNS canisters. This includes tool support for developers to initialize SNSs as well as processes that allow SNSs to automatically upgrade themselves to the newest version.

10. Custom Subdomains

Conversation Lead: Rudiger Kapitza

CanisterId-based URLs, such as ​​https://7e6iv-biaaa-aaaaf-aaada-cai.ic0.app, are hard to read and memorize. This feature will enable developers on the platform to create custom subdomains on ic0.app for their canisters. For instance, a developer could create a custom canister name for their canister such that .ic0.app resolves to their <canister_id>. This is the first step towards enabling arbitrary URLs.

11. Deterministic Time Slicing

Conversation Lead: @bogwar @akhilesh.singhania

Currently, the amount of computation a canister can perform per call is limited by the block time. Deterministic time slicing allows for long(er) running, multi-round computations by suspending the execution at the end of one round and resuming it later.

  • Proposal link: none
  • Forum link: none

12. Community Fund

Conversation lead: @jwiegley

The community fund is going to be made up of a set of neurons, whose funds are committed to being invested in IC dapps by enabling the “community fund” flag in those neurons. These ear-marked funds will be eligible for investment into communities that use an SNS, for example by providing liquidity in the form of ICP for its tokens or funds for dapp developers. The exploration and definition of the exact form of such investments is part of this feature.

  • Proposal link: none
  • Forum link: none

As always, feedback, questions, are all welcome!


Oh hell yeah. :100::100::100:


Thank you for this. Existing days ahead!


Question for you Diego:

Are we able to verify the code that a canister is running? For example, given some Motoko/Rust code, can we verify that a canister is indeed running that code? I know something similar is possible on EVM chains.

The reason I ask is because HTTP requests from canisters sound great, but then this opens a can of worms. It’d be nice to verify canister code.


Good question. Yes canisters’s code can be verified (and it is their designed intent to serve as smart contracts one can trust).

I believe this is what you are looking for: Verifying the Internet Identity Code: A Walkthrough | by DFINITY | The Internet Computer Review | Medium

To be fair, I could have sworn I heard there may be some cases where there are practical limitations as to what can be verified consistently. @jwiegley @PaulLiu does this ring a bell?

1 Like

Thanks for the speedy reply, Diego. I’ll give this a read!

1 Like

You are very much welcome!

@Mr_Burkes you may also be interested in this.


Thanks a bunch, Paul!

I should note that the current R&D project on Verified Canisters goes further than what is presented in the Medium article. In addition to validating that a canister is running a specific source artifact, it should also be possible to query the canister directly for other pertinent information, such as an attestation report or a security audit. These source artifacts would be tied to the WebAssembly in a manner conducive to validation by a third party.


If we are just talking about whether some source code after compilation becomes a Wasm binary with a matching hash to what is installed in a canister, then yes we can already do that by making sure the compilation from source to binary is fully deterministic.

It can still be tricky though, depending on which language, toolchain, libraries, and even operating system you use, and how exactly you pin down their versions.

Say if I compile on my machine twice and got the same wasm binary. Is it good enough? Maybe not, maybe I should have github CI compile it and see if that gives the same binary. But that may be still not good enough. who knows if a month from now re-running the CI will still give the same result?

In some of my projects, I tried to make sure the canister’s wasm binary is reproducible and can match what is installed in the canister. For example, the black hole and the QR scanner.

But this is reproducibility, not exactly the same as verifiability. Say if 10 independent parties are able to compile to the same result and they sign their signature on both the source and the binary to vouch for it, then maybe that is good enough already. I think governance like SNS will be able to help in this regard.

But code is complex and their behavior not always well understood even when the source is available. We have seen numerous hacks of EVM smart contracts due to careless programming mistakes or purposely planted backdoor. Is showing the source code the best way to gain trust? I don’t have a good answer, but I think as an industry we are still at the infancy of practicing software verification. We should and we will do better.


^ Well, that’s an understatement. :rofl:


Are there any milestones in Q1 2022 about allowing community members to make open source contributions to the IC code base?

So, for example, we can implement our own NNS motion proposals?

Unrelated, how is DFINITY internally handling burnout? Development towards a project as ambitious as blockchain singularity is more of a marathon instead of a sprint. Is this impressive (truly impressive) pace of development sustainable going forward, and are there tried and true ways that are being attempted to help fight burnout?

Ooos Thats a typo on my part!

You can certainly create motions.

I need to update the docs, but I’ve written on the forum on instructions I use to submit.

The project of “furthering open source contributions”continues. I’ll ping @ali.piccioni to give an update. To your point, I don’t think there has been a public update on this project since December.

1 Like

I was thinking more along the lines of writing and deploying the code that actually implements the vision behind of a motion proposal, not the act of creating the proposal.


On a high level, these milestones are super exciting, but I worry if they are a bit too ambitious for Q1 2022, which ends in 2 months…

The ICOS boundary nodes, SNS, community fund, and enable HTTP requests from canisters milestones strike me as optimistic, although of course I don’t have any insight (besides SNS) into their current statuses…


Ah then yes, the project in furthering contributions is what you are looking for:

I agree it is due for an update from team: