Skip to content

batchAttestHolding fails with IC0406 #4

@HavenCTO

Description

@HavenCTO

Problem
When we added the batch attestation feature, the canister started failing on remote calls.

On the Internet Computer, every canister must maintain a freezing threshold—a reserve of cycles guaranteeing it can stay alive for the next 30 days.

The issue is that our new batch process is very expensive. It's expensive because it must pay a separate cycle fee for every individual vetKD key derivation requested to decrypt the content access. Batching multiple attestations together stacks those individual key derivation fees into a massive total cost, which quickly consumes the canister's available cycles above the freezing threshold, causing the runtime to reject the call before it can even complete.

When the canister attempts to execute this batch, the combined cost of the vetKD key derivations plus the required freezing threshold exceeds the canister's available cycle balance. Because the system refuses to allow a transaction that would dip into the freezing reserve, it rejects the remote call entirely.

Solution
We are replacing the current batchAttestHolding endpoint with an IPLD-based Merkle tree approach that requires only a single Schnorr signature per batch, resolving the cycle exhaustion issue.

Full proposal: IPLD Batch Attestation Proposal

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions