Update on the IC Roadmap: December 2022 Summary

This is an overdue roadmap update. The last one was published in September. Meanwhile, we are close to the end of the year. We are proud of some recent releases that included major features that kept us busy for many months. We will also provide an update of the 2022 highlights in today’s public global R&D.

We stick to the categories/domains used in the past roadmap updates and highlight the top items that we work on or have released recently.

Core protocol: Every now and then, community members voice concerns that the foundation invests too little into the core protocol. I want to point out that the percentages on top of the roadmap columns indicate the share of the team working in the respective area. You can see that by far the biggest effort keeps going into the protocol.

  • Code Bitcoin: In the beginning of December, we finally launched the Bitcoin integration. This milestone completed a longer beta phase. We are excited to see various developer teams building on top of this technology. You may also want to check out the dedicated dashboard.
  • Chain-Key Signatures: A key building block for the Bitcoin integration is tECDSA that allows canisters to create ECDSA signatures in a decentralized fashion. tECDSA, often branded as Chain-key Signatures, is a powerful capability beyond the Bitcoin integration. For example, @domwoe and Ben Lynn demonstrated a Uniswap frontend running on the IC combined with an ECDSA signing canister. During the Bitcoin integration beta phase, we further improved tECDSA security by implementing a rotation of IDKG encryption keys.
  • 48 GiB stable memory: canisters can now make use of 48 GiB stable memory. Previously, we aimed for 32 GiB and communicated accordingly. But we determined that 48 GiB is possible. This is a 10x bump from the 4 GiB where we started at the beginning of this year.
  • Higher-replication subnets: As demonstrated in November by @dsarlis, developers will soon be able to choose the replication factor of the subnet on which their dapp is deployed. Higher replication means stronger security guarantees but also burns more cycles. Lower replication subnets that consist only of a few nodes will follow in the future.
  • Inter-canister query calls (ICQC): is a functionality asked for by many developers. @ulan presented the technical tradeoffs related to ICQC and a rough roadmap towards full ICQC support in September.
  • 100k canisters per subnet: Currently an IC subnet may slow down if the number of canisters running on it goes beyond 50k. The exciting growth of some dapps hosted on the IC increases the need to address such bottlenecks.
  • Support larger WASM modules: The relatively small size of WASM modules supported by canisters today prevents developers from building dapps depending on large libraries. We plan to lift this restriction soon.
  • Safe canister upgrades: Currently, canisters cannot be upgraded safely without stopping them to ensure there are no outstanding calls. By introducing named callbacks, canisters can be upgraded without stopping, ensuring that canisters can always be upgraded.
  • On-chain encryption: As explained by @ais and @gregory, this feature will bring end-to-end encryption (confidentiality) to user data stored on the IC.


  • Custom domains: as demonstrated by many developers, e.g. dscvr.one, dapps can be reached by custom domains. However, so far, they rely on web2 infrastructure. With this feature, it will be possible to manage your dapp’s custom domains through a canister hosted on the IC.
  • Certified headers: Today, the IC only supports certification of response bodies (e.g., static assets). This feature introduces flexible certification that allows the dapp developer to specify the header fields and assets to be certified, a prerequisite for better caching.
  • WebSockets provide a bi-directional communication channel between the client (dapp frontend) and the canister (dapp backend). We started to prototype a WebSocket solution in collaboration with Psychedelic. This enables canisters to push notifications directly to the client and to dynamically update dapp content.

System utils / dapps

  • NNS FE dapp: The GIX team has been working hard to extend the NNS FE dapp for the SNS. In parallel, the dapp underwent multiple design and user experience improvements. We are happy to see how the community appreciates these changes and are committed to further improve the experience.
  • ckBTC: As demoed in November by @Manu and Leo, the team is currently building the infrastructure for an ICRC-1 compatible token, called ckBTC, that “chain-key-wraps” Bitcoin. We aim to launch in January.
  • ICRC-2 token standard: As first ICRC-1 ledgers see the light of the day, the ledger and token working group continues to define ICRC-2. ICRC-2 is an extension of ICRC-1 and specifies a way for an account owner to delegate token transfers to a third party on the owner’s behalf.


  • SNS-1: The launch of the first SNS-decentralized dapp, SNS-1, was a major milestone with huge contributions from many teams. Even though this launch was only considered an experiment, we often called it a “dress rehearsal”, it attracted a lot of community members to participate and created a lot of excitement. We also faced some problems and discovered limitations, which @lara summarized in an extensive lessons learned post.
  • Community proposals: We are aware that we didn’t give enough attention to some adopted community governance proposals. For the next few weeks, we anticipate to still be fairly busy with the SNS but we up-prioritized these proposals and plan to tackle them next.


  • dfx shared replica: The SDK team releases a stream of dfx updates, packed with quality-of-life improvements. For example, the IC emulator included with dfx is now available system wide.
  • Motoko VS Code extension: We improved the VS Code extension for Motoko as demoed by @rvanasa in October. There are many additional Motoko improvements waiting for Motoko devs to be discovered.
  • Motoko garbage collection: Building on Deterministic Time Slicing (DTS) released earlier this year, the Motoko team is working on a generational garbage collector (GC), which will reduce cycle costs and allow heavier computations.
  • Documentation: We are working on a general overhaul of the developer documentation. We start from the very beginning with a significantly simplified “hello world” and plan to work our way up to more complicated tutorials and explanations.

Platform Engineering

A very busy year comes to an end. The list above is already fairly long and it’s only the tip of the iceberg. May more team members should have been mentioned but the forum only allows me to mention 10 per post. A big “thank you” to all the community members for their active engagement and feedback. Have a great holiday and we look forward to continuing building the IC and its ecosystem with you in 2023.

Updated on 2022-12-15 adding “safe canister upgrades” that was missing in the initial post.


Hey @samuelburri ! Can we put the name-callbacks feature on here? @Manu can you help? Name-callbacks are a requirement for creating frameworks based on standards that anyone can implement. Name-callbacks are a requirement for canister upgrades without stopping, and for a canister to self-upgrade. A lack of the named-callbacks has led to the unfortunate use of the “one-way calls” hack where most users of it are unaware of its workings. The icp ledger once had to remove it’s notify method because of the security vulnerability that a canister could prevent the ledger from upgrading by withholding a callback/response, and the ledger needed to stop before upgrading because there was no named-callbacks.


Yes please, the possibility of a new token standard based on reliable notifications would by itself be enough to have named callbacks on the roadmap.

1 Like

Thanks for flagging @levi, I think the omission of safe canister upgrades might have just been a mistake and it’s still on the roadmap. I’ll double check and follow up here.

Edit: confirmed that safe canister upgrades are still on the roadmap but accidentally didn’t make it into the overview that Sam shared. This will be updated!

Awesome! Thanks @Manu :pray:.

1 Like

@levi @Manu thanks for pointing that out. I missed to add “safe canister upgrades” when I created the initial post. It’s added now.


I think one conversation that may be worth starting is whether we will have subnets that support various hardware accelerators, namely GPUs.

There seems to be a growing trend of heterogeneous computing, where special categories of software are offloaded to an accelerator for processing. Prominent examples include machine learning and cryptography. My feeling is that this trend will only accelerate in this decade.

What will it take to support GPUs in Gen3 node hardware? I know it’s a bit premature, but I think there is value in thinking through what the economics (and technical effort) of that would look like.

1 Like