What are delegations?

Starknet and other EVMs call these “session keys”, which all do the same thing. They are essentially a key—limited in time and permission—to let the user skip signing individual transactions during use.

For the ICP ecosystem, that means developers receive a principal that’s been pre-approved to call some (or all) canisters for a period of time without the user’s explicit approval for each call.

What is an ICP wallet address?

For the purposes of explanation, we use a valid textual representation of an ICRC1 account to describe an ICP wallet address, and simplify further to use principal as the main wallet address.

Types of delegations

Given that malicious developers may try to use delegations to manipulate data in other canisters (i.e. ledgers), the ICP ecosystem has evolved to use two types of delegations:

• A delegation specific to the URL (i.e. Relying Party delegation), and
• A delegation for the wallet address (i.e. Account delegation)

Relying party delegations can be used to make authenticated calls to any ICP canister, but using these will isolate your application from the rest of the ecosystem because users will not be able to use those wallet addresses outside your app.

Account delegations can be used to make authenticated calls to your own canisters, and will require approval to call others.

Recommendation

We believe Web3 is about having a universal digital identity that people can use to bring their data and assets from app to app. Therefore our bias is to always ask users connect with their wallet address. Let users connect with a new Account or Relying party delegation if they don’t yet trust your app, but always strive to decrease how much users need to trust your service to use it.

Read more about target canisters and the ICRC-28 standard.

Read about the differences working with accounts and delegations.