Introducing ICRC-112 Batch Canister Call and ICRC-114 Validation Canister Standards

Developers
1

Hey everyone,

I’m excited to introduce two new standards I’ve been working on with the Identity and Wallet Standards Working Group: ICRC-112 Batch Canister Call and ICRC-114 Validation Canister. These proposals enhance canister interactions on the Internet Computer (IC) by improving UX and ensuring secure validation.

ICRC-112: Batch Canister Call

Link to spec

ICRC-112 improves the user experience by bundling multiple ICRC-49 canister calls into a single, sequenced request.

  • What it does: It allows a signer (like a wallet) to package several canister calls (e.g., token transfers, updates) into one batch, using a sequence to maintain the order of execution. The IC processes these as a single submission, though each call’s outcome remains independent—not atomic.

  • Use case: Imagine a user swapping tokens across multiple ledgers in a DEX. ICRC-112 bundles those calls with a defined sequence, so the wallet submits them in order without multiple confirmations.

Built on ICRC-49 (single canister calls), this standard streamlines multi-call workflows. But when the signer can’t validate certain methods in the batch, ICRC-114 comes into play!

ICRC-114: Validation Canister

Link to spec

ICRC-114 provides a validation canister, supplied by the relying party, that the signer uses to validate unsupported methods in an ICRC-112 batch.

  • What it does: After submitting an ICRC-112 batch request, the signer can’t always parse the response (e.g., swap). It calls the relying party’s ICRC-114 canister, which provides a method to parse the response and determine the next steps in the sequence.

  • Use case: After submitting an ICRC-112 batch, the wallet (signer) gets a response it can’t parse (e.g., swap). It queries the relying party’s ICRC-114 canister, which parses the response and guides the wallet on how to proceed with the sequence.

Paired with ICRC-112 and informed by standards like ICRC-25, ICRC-114 ensures the signer can handle batch responses securely and efficiently.

Why These Matter

ICRC-112 and ICRC-114 make the IC more seamless and reliable. Batch Canister Call sequences multi-call operations for better UX, while Validation Canister helps the signer interpret responses via the relying party’s logic.

What do you think? Any use cases where these could excel, or ideas to refine them? The specs are still evolving, so your feedback is invaluable. Check the links above for the details, and let’s chat!

1 Like
2

A signer is like a service that you delegate to? This might be a wallet extension or a third party wallet service? Can it be a canister(or rather is it safe for it to be a canister…you still can’t delegate to a canister right?)?

I seems to have some functional parallels with ICRC-48, but 48 was specifically targeting canisters as the executor of workloads.

3

See the signer part in the overview: wg-identity-authentication/topics/signer_standards_overview.md at main · dfinity/wg-identity-authentication · GitHub

A component that holds a private key and can sign messages. In addition, the signer needs to be able to interact with the IC to send messages and receive responses. It can be a hardware wallet, a mobile app, a browser extension, or any other component that can sign messages.

In practice, a canister could be a signer, if you’d define a transport that uses canister calls. Though even a canister signer will likely have a frontend component that is probably more straightforward to communicate with than the canister directly. Right now, we’ve currently only standardized transports for web and extension signers in the WG.