Create a sub-organization
getWebAuthnAttestation
. See this example.Your application then uses an API-only user to create a new sub-organization on behalf of the end-user with a CREATE_SUB_ORGANIZATION
activity. In the example below, the new sub-organization has one root user controlled by the end user’s passkey, and an associated Ethereum wallet:CREATE_SUB_ORGANIZATION_V4
activity here.Wallet creation
CREATE_SUB_ORGANIZATION
activity accepts a wallet
parameter!), your end-users can derive more accounts or create more wallets after the fact by using their passkeys to sign a CREATE_WALLET
activity.We’ve abstracted getting WebAuthn signatures and creating signed Turnkey requests behind typed methods (e.g. createWallet
).Our TurnkeyClient
(from @turnkey/http
) can be initialized with a WebauthnStamper
(from @turnkey/webauthn-stamper
):signedRequest
, which contain all the components needed to forward it to Turnkey: URL, body, and a stamp header (with name and value properties). Use httpClient.stampCreateWallet
to get a signed request. Your backend server can then proxy it to Turnkey.Next, we can derive additional accounts (addresses) given a single HD wallet. The shape of the request is as follows:Transaction signing
SIGN_TRANSACTION
activity with their passkey. In your application, a user action (for example tapping a “Withdraw Rewards” button) might trigger the flow. The details of this transaction should be presented to the user for confirmation, followed by a passkey prompt to sign the Turnkey activity. An activity to sign a transaction looks like the following:The end-user must provide a signature over each SIGN_TRANSACTION
activity with their passkey. In your application, a user action (for example tapping a “Withdraw Rewards” button) might trigger the flow. The details of this transaction should be presented to the user for confirmation, followed by a passkey prompt to sign the Turnkey activity. An activity to sign a transaction looks like the following:CREATE_SUB_ORGANIZATION_V4
activity becomes:
"authenticators"
list!)
Key creation and signatures can also be performed with this root API user, and the end-user doesn’t need to be involved in the activity signing process.
Policies can be use to segregate permissions if needed: you could, for example, bootstrap each sub-org with 2 API users: one to create keys and setup the organization policies; the other to sign transactions.
@turnkey/sdk-browser
, @turnkey/sdk-react
and @turnkey/sdk-server
packages and includes features such as:
@turnkey/ethers
for signing and WalletConnect (v1) for accessing dapps.
@turnkey/ethers
signer, using passkeys.
@turnkey/viem
signer, using passkeys.
@turnkey/viem
signer and @gelatonetwork/relay-sdk-viem
.