Turnkey has built a new model for private key management that utilizes secure enclaves. All transactions are signed within an enclave and private keys are never exposed to Turnkey, your software, or your team. Turnkey’s role is similar to that of a safety deposit box operator — Turnkey secures and provides access to the safety deposit boxes, but our system requires cryptographic proof of ownership to take any action with the keys held within.
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.
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:
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: