Custody Providers

Internet Computer Integration for Custody Providers

This document is aimed at product owners and architects at custody providers who’d like to get an overview of the integration tasks ahead, before diving deeper into implementation details.

Introduction to ICP and what You need to know about the Blockchain

First, the Introduction to ICP.

Second, it's worth repeating that a node in the terminology of the IC refers to a computer executing canisters (i.e. the smart contract / WASM runtime). Custody providers do not interact with these nodes. Instead, they integrate with Rosetta (see below) or so-called boundary nodes. API boundary nodes provide a public endpoint for the IC and route all incoming requests to the right subnet, load-balance requests across replica nodes, and cache responses for improved performance.

Cryptography

Parties that send requests to the Internet Computer authenticate themselves via a digital signature on a 32 byte digest of the request. Currently supported signatures are vanilla Ed25519 and ECDSA (over secp256r1 and secp256k1) digital signature schemes. In addition, authentication can also use WebAuth signatures (either ECDSA on secp256r1 or RSA PKCS#1v1.5, both using SHA-256.)

Outgoing information is authenticated by (threshold) BLS signatures, verifiable wrt to a global master public key.

Balances and Transactions

Balance and transaction information needs to be polled from Rosetta API or a boundary node.

Integration with Rosetta

DFINTY’s Financial Integration team provides a Rosetta API docker image for custody providers and other infrastructure providers building on the IC. Rosetta is an open standard designed by Coinbase to simplify blockchain deployment and interaction; this allows custody providers to spend less time on integration and more time on novel blockchain advancements.

Native Integration

If using the Rosetta API is not feasible for whatever reason, then custody providers interact with the network directly through a boundary node.

To integrate tokens on the ICP blockchain (including the native ICP token) providers need to interact with the smart contracts that maintain the tokens.  This requires familiarity with:

• the execution model of the IC
  • requests are submitted, and replies need to be polled
  • different types of requests yield different levels of trust in the response
• Candid, the service description language

Staking

ICP staking is kind of like delegated PoS, but also different in key areas.

Main facts of relevance for custody integration:

• Staking rewards are earned through ICP lock-up (6m-8y) and participation in on-chain governance (~10 votes/day), not through validation of blocks.
• There is no separate validator infrastructure, things happen on-chain.
• Every staking entry creates a so-called Neuron. A private key (and principal ID) can have many neurons.
• Staking properties (timing, unlock, rewards, voting) are managed at the Neuron level
• Most Neuron metadata incl. amounts, staking timelines, etc. are not public on-chain, instead need to be queried using signed transactions
• Voting can be delegated to other staking participants, it is called to “follow a neuron”. This is the recommended setup, we don’t expect custodians to vote 10 times daily…
• Leaving staking starts with “dissolving” a neuron, at which time the unlock timer starts (e.g. 8 years) and the rewards are reduced
• Getting maximum rewards requires (i) maximum lock-up (8y), (ii) that the neuron is not in dissolving state, and (iii) that all votes are voted on (yes or no - pass does not count)
• Accumulated rewards can be (i, the default) restaked automatically, (ii) automatically participate in the on-chain social fundraising activities (“Neuron’s Fund”) on SNS, or (iii) be liquidated after a 7 day waiting period, which starts with manual “spawning” of rewards ICP staking does not require a validator infrastructure or any other on-line infrastructure as all the on-line operations are facilitated by the Internet Computer
• Staking support is implemented in the Rosetta container using a documented but unofficial API extension, as the main standard is tailored for D-PoS

Token Standard

The ICRC-1 standard was created to facilitate handling of tokens on the IC through a common interface, similar to ERC-20. This standard is a key enabler for DAPPs developed on the IC launch their own token, i.e. tokenize and hand over control over the DAPP to a community of users, hence functioning and being governed as a DAO (“decentralized autonomous organization”). It is expected that all tokens support it going forward.

ICRC-1 tokens may use the SNS for on-chain governance similar to how ICP uses the NNS. We expect to provide a Rosetta API container for SNS and ICRC-1 tokens in about 6 months with 100% API compatibility to the main ICP Rosetta API (pending roadmap confirmation).

SNS and NNS have close but not 100% API compatibility, which needs to be considered when using native integration on a Boundary node.

Integration with the NNS Front-end

Mentioned for completeness sake: the IC operates an on-chain online wallet for rapid on-boarding of end-users with negligible amounts of assets. It is not recommended for institutional use or a significant amount of assets.

Users create an identity on the Internet Identity service, which under the hood creates a private key and distributes it on-chain using TSS and chain-key cryptography. Users then use the NNS Front-end to manage their assets, including staking. Access to these websites is protected using Passkeys or a seed phrase.