Define the permitted actions
A session specifies which chains, contracts, and functions your application can use. Parameter rules can fix a recipient or cap an amount, while time windows and usage limits bound how long and how often an action remains available. These permissions are enforced onchain by the account’s session-key validator. Calls outside the approved scope are rejected, even if your application submits them. For crosschain workflows, permission to execute on the destination chain is separate from permission to claim assets on a funding chain. A session must explicitly authorize both.Application-held signing
Your application holds the session private key. Rhinestone stores public grant metadata and coordinates transaction preparation and submission, but does not receive that key. Anyone with the key can exercise its remaining permissions. Use narrowly scoped, short-lived grants and protect the signer accordingly. Deleting a local key does not revoke its onchain authority, and the current app-origin SDK does not expose a revocation method. See Security for custody and revocation boundaries.Get started
Start with an authenticated embedded wallet, then define the authority your workflow needs.Choose an integration path
Both paths configure the same onchain validator, so the permission model and its enforcement are identical. The setup differs. Embedded wallet is the default. The user grants the session with their passkey, your application holds an ECDSA session signer, and Rhinestone prepares and submits each later intent. The guides above cover it. Custom setup covers accounts your own stack creates and operates:- Agent wallets — an account an autonomous agent transacts from, with the session’s permissions bounding what it can do.
- Backend-only wallets — an account with no end user, operated entirely by your service.
- Your own signer — an account owned by an external wallet, a key you hold, or a multisig rather than a Rhinestone passkey.