Security and self-custody

Embedded wallets use passkeys to control onchain smart accounts. The passkey’s private key stays with the user’s authenticator; Rhinestone receives the public key and signed WebAuthn responses, not the private key. This design removes a server-held transaction key from the normal signing path, but self-custody is more than key storage. Evaluate the complete control path, including transaction cosigning, service availability, and recovery guardians.

​

Transaction control

A normal embedded-wallet transaction combines two approvals:

• The user’s authenticator signs the prepared payload through WebAuthn.
• Rhinestone adds a request-scoped co-signature before submitting the transaction.

The service cosigner cannot authorize a transaction without a valid WebAuthn signature. Conversely, the managed transaction path depends on Rhinestone to prepare, cosign, and submit the request. This prevents the service from spending with its cosigner alone, but it does not mean the service is absent from transaction availability. WebAuthn binds the credential to its relying-party namespace. Passkeys are created and used on your verified application origin. A copied integration on an unrelated origin cannot invoke that credential. See Passkeys and domains for the namespace and deployment requirements.

​

Recovery is an authority path

A recovery guardian can authorize adding a new passkey. It cannot directly sign an ordinary transfer, but adding a signer changes who can control the account. Include that authority when assessing custody and operational risk. In the currently released verified-identity flow, Rhinestone operates the managed recovery guardian and its signing service. The service applies the email or OAuth identity policy offchain before signing. Onchain, the account checks that the installed guardian signed the exact replacement-passkey parameters; it does not verify that offchain identity policy. Whoever controls or compromises the guardian signing capability can authorize an attacker-controlled replacement passkey and then gain control of the account. The available recovery path depends on how the account was created:

• Passkey-based recovery can derive a user-controlled guardian from WebAuthn PRF output when the authenticator supports it.
• Verified-identity recovery uses the Rhinestone-operated guardian described above.
• An application guardian or Custom signer guardian places the equivalent recovery authority under infrastructure and policy controlled by the application or its chosen operator.

Configure the intended fallback during account creation. Follow Recovery setup for the released embedded-wallet flow and Trustless recovery for the canonical service-independence model and its current availability.

​

Trusted execution environments

The user’s WebAuthn authenticator may use secure hardware, but normal passkey signing does not rely on a server-side trusted execution environment (TEE). The released managed recovery path uses an operator-run policy service and AWS KMS signing; its identity policy is not enforced by an enclave. A TEE-based recovery signer is under development. The current implementation includes policy code and initial AWS Nitro Enclave runtime wiring, while production image, deployment, key-policy, and release work remain. Do not treat enclave isolation or public attestation as a guarantee of the released recovery service until that deployment is live and independently verifiable.

​

Service outage and portability

Assets remain at the smart-account address. After deployment, the account enforces its signer and guardian configuration onchain. An account can remain counterfactual before its first deployment, so do not assume every new account’s configuration has already been written to a chain. A Rhinestone outage does not move or freeze the assets, and the service cosigner alone cannot transfer them. This cosigner limitation does not remove Rhinestone’s account-control authority through its managed recovery guardian. Access during an outage is a separate question. The managed SDK transaction path needs Rhinestone’s preparation and cosigning services. Passkey sync can help a user retain the credential across devices, but sync behavior belongs to the user’s platform or password manager. Recovery during a prolonged outage requires a guardian path that does not depend on the unavailable service; plan and test that path before relying on it.

​

Integration responsibilities

• Serve WebAuthn over HTTPS and register every authorized origin.
• Keep the RP ID and account namespace stable; changing them selects a different credential and account.
• Show an accurate transaction review before blind signing, or use the supported clear-signing flow for higher-risk actions.
• Protect sponsorship endpoints and scope session keys to the minimum required authority.
• Choose a recovery policy during account creation and explain its trust assumptions to users.
• Test account access, passkey loss, and service-outage procedures separately.

See Sign up and sign in for authentication behavior and Clear signing for transaction-review options.

​

Compliance considerations

Passkey-controlled accounts can support a self-custodial product design because the provider does not hold the user’s passkey private key and cannot transact with its cosigner alone. However, the currently released verified-identity flow gives the Rhinestone-operated recovery guardian authority to approve a replacement passkey and thereby enable account control. Application-operated and Custom signer guardians place that authority with their respective operators instead. These facts do not determine a legal classification by themselves; recovery authority, operational control, transaction availability, product terms, and jurisdiction can change the analysis. Treat this architecture as input to your own legal and compliance review, not as a representation that an integration automatically qualifies as non-custodial or receives a particular regulatory treatment.