Multi-users account

Multi-users account covers accounts with several signers, inviting users to an existing account, updating their roles, and allowing them to create their own passkeys.

​

Which accounts can have multiple users

Both entity and individual accounts can have more than one signer (root user), each controlling the account with their own passkey:

• Entity accounts are multi-user by design: each root user and each beneficiary/representative is a separate person. Someone can be a signer without being a UBO, and a UBO without being a signer.
• Individual accounts can now also have several signers. Every signer is listed in the rootUsers field of the create-individual-account call, mirroring how entity accounts are created.

​

Creating an account on behalf of a client

A wealth manager / CGP can create and manage an individual account for a client. This relies on the split between the verified customer and the signer:

• userInfo — the client. They are the KYC subject and appear as the account’s customer from the moment it is created.
• rootUsers — the signer(s), for example the wealth manager, who control the account with their own passkeys.

The client is the account’s customer immediately, even before they sign anything. When they are ready to take part in signing, invite them with the standard invitation flow below. Once they accept and create a passkey, they become a signer (or root user) alongside the CGP.

​

High-level flows

​

Invitation-to-account

​

Updating roles

​

Technical implementation

​

Inviting users

1. Get invite users payload — Request the payload that a root user must sign with their passkey to invite new users to the account. Use this endpoint to get the payload:

2. Submit signed invite-users payload — Then call the below endpoint with the signed payload to execute the invitations:

​

Accepting an invitation

1. Initialize OTP for a user — Initialize an OTP for the invited person to authenticate by calling this endpoint:

2. Authenticate with OTP — Invited user enters the OTP code to create a session and authenticate with OTP. Call this endpoint to submit the authenticated session to accept the invitation:

3. (Optional) Create a passkey for the new member — Allow the new user to create a passkey by using the below endpoint. The user must have an active OTP session (from step 1 and 2).

Invitations can be listed per account or per email via the get-invitations-by-account-id and get-invitations-by-email endpoints.

​

Promoting and demoting roles of a member

• Get update users role payload — Request the payload that the root user must sign to change users’ roles. Call this endpoint:

• Submit the signed payload — Then call the below endpoint with the signed payload to execute the role update:

​

Roles and permissions

Four different roles exist:

• root: The root user is the admin of the account and has full permissions.
• view: The view user can only view the account and cannot make any transactions.
• beneficiary: Beneficiary users are UBOs of an entity account at the moment of creation. By default, they cannot make any transactions.
• self_custodial: All accounts created with a self-custodial wallet have this role.

The roles and permissions are described in the table below: