Are chain-key signing costs sustainable for wallets and high-frequency applications? The OISY example

Developers
1

I would like to raise a concern about the long-term operating cost of applications that rely heavily on chain-key signatures.

OISY Wallet is a useful real-world example. For native assets such as BTC, EVM assets, and SOL, OISY uses the NNS-controlled Chain Fusion Signer and pays the signing cost on behalf of users through PatronPaysIcrc2Cycles.

From the public OISY source code, each user receives a signing allowance of approximately 2.917T cycles. The allowance is refreshed when it falls below approximately 1.458T cycles, and it has no time-based expiration. This is an ICRC-2 spending allowance rather than an immediate expense, but the actual cycles are ultimately pulled from a shared OISY backend account whenever users sign.

OISY also monitors that shared account and automatically tops it up when its balance falls below 50T cycles. The repository contains an integration test explicitly described as reproducing a production send outage: once the shared patron account was drained, BTC, EVM, and SOL signing failed with InsufficientFunds until the hourly top-up refilled the account.

This suggests that signing cost is not only a theoretical pricing issue—it is already an operational availability concern for a production wallet.

According to the current Chain Fusion Signer documentation, a standard ECDSA or Schnorr signature costs 37B cycles, plus the Cycles Ledger transfer fee. BTC operations are considerably more expensive because their fees scale with transaction inputs and, for sends, outputs. The underlying production sign_with_ecdsa management call still costs approximately 26.15B cycles.

At low usage these costs may be manageable as a user-acquisition subsidy. However, they become significant when an application grows. For example, 10,000 active users making only 10 standard signed operations per month would generate around 100,000 signatures, costing approximately 3,710T cycles per month through the Chain Fusion Signer. At 100,000 active users, the same usage pattern would reach approximately 37,100T cycles per month, before considering BTC operations, RPC calls, canister compute, storage, monitoring, and other infrastructure.

The same concern extends beyond wallets. If a canister-based protocol requires chain-key signatures for frequent external-chain settlement, automated trading, rebalancing, custody, or other high-frequency operations, the operator must either subsidize a rapidly growing cycles bill, introduce strict quotas, or expose a relatively high per-operation fee to users. This appears difficult to reconcile with consumer-wallet expectations and high-frequency decentralized applications.

A 2023 forum proposal discussed reducing threshold ECDSA signing prices by 50x, together with future protocol and throughput improvements. However, the current documented production price remains around 26.15B cycles, while the Chain Fusion Signer charges 37B cycles for a standard signature.

Could the DFINITY team clarify the current direction?

  1. Is a substantial reduction in production chain-key signature pricing still planned?
  2. Is the current 37B-cycle Chain Fusion Signer fee expected to remain the long-term price?
  3. Are batching, delegated/session signing, lower-cost signing tiers, or new threshold protocols being considered for high-frequency applications?
  4. Is there an official recommended funding model for production wallets and applications: patron subsidy, user-paid cycles, quotas, subscriptions, or something else?
  5. Does OISY intend to subsidize native-chain signing indefinitely, or is its current model mainly an interim adoption strategy?

Chain-key signing is one of ICP’s strongest capabilities, but its long-term adoption may depend on whether applications can offer frequent signing without turning every successful user into a substantial recurring operating expense.

Relevant references:

2

https://github.com/dragginzgame/canic/

Point your LLM at that repo and ask the question.

3

I don’t understand.

How does canic bypass or reduce the chain fusion signer cycle costs to other blockchains?

4

To expand on my rather compressed reply: I linked Canic because it implements a concrete example of the batching and delegated/session-signing approach you asked about in question 3.

Canic does not use an expensive chain-key signature for every user action. It moves chain-key signing into the control plane, where one signature authorizes a bounded batch of issuers. Those issuers can then serve large numbers of short-lived application authorizations using IC canister signatures.

That does not answer DFINITY’s pricing roadmap, and it cannot eliminate signatures that BTC, Ethereum or Solana require for native transactions. It does show how many high-frequency application operations can be separated from high-frequency chain-key signing.

A longer explanation of what I meant

Canic has a Fleet Root that acts as the chain-key trust anchor. Rather than asking the threshold ECDSA subnet to sign every user token or application operation, the Root constructs a Merkle-rooted batch containing delegation certificates for up to 64 issuer canisters.

The Root makes one sign_with_ecdsa call over the batch header. Each issuer receives its certificate, Merkle witness and the shared Root signature. Once installed, those issuers can produce short-lived, audience-bound and role-bound authorization tokens using IC canister signatures.

The relevant implementation is here:

The important economic distinction is:

  • Without delegation, the expensive operation can sit on the request path and grow roughly with the number of user operations.
  • With Canic’s model, the expensive operation sits on the renewal path and grows with the number of delegation batches and renewals.
  • Potentially millions of ordinary authenticated calls can occur beneath a comparatively small number of Root signatures.

This is not merely grouping 64 ordinary signatures into one call. One Root signature establishes a temporary trust relationship with multiple issuer canisters. The downstream requests are then authorized through scoped, expiring delegations rather than additional threshold ECDSA signatures.

There is an important limitation, which your OISY example exposes. A native BTC, EVM or SOL transaction ultimately needs a signature accepted by that external network. An internal Canic authorization token cannot replace that signature.

If a wallet can use smart-account session keys, delegated spending keys, batched settlement or another native protocol mechanism, it may be possible to move some activity underneath a less frequently renewed chain-key authorization. Where the destination chain requires a fresh threshold signature from the same account for every transaction, the underlying per-transaction cost remains.

So I am not suggesting that the Canic repository answers whether 26.15B or 37B cycles is the correct long-term price. It demonstrates that high-frequency application authorization does not necessarily require high-frequency chain-key signing.

Your pricing and OISY-funding questions remain valid for irreducible native-chain signatures. Canic is my concrete example of how the delegation and batching part of the problem can already be addressed at the application architecture level.

5

Ah, I see now. That makes sense.

Thank you for sharing your work here.