DOCS / SCOPED SESSIONS

Delegate within your rules.

Delegate supported native transfers within explicit bounds. A registered policy determines whether a valid session can replace per-operation approval.

Sessions are deferred for the hosted v2 quickstarts and message demo. They use exact per-request authentication, with an optional program commit. Bound ephemeral keys are not scoped sessions. This page documents the core and lower-level SDK transfer-session flow; start with Policy & rules to choose the right authorization model.

Authorize a session

For supported Solana and EVM native transfers, a session grants bounded permission to a delegate. The grant binds the signing account, destination, recipient, per-operation limit, policy version, and expiration. EVM grants additionally bound gas price and total fees.

Eligible session-only requests do not need a new Solana authorization transaction for each signature. Zero per-signature Solana transaction fees means precisely that: grant creation, revocation, destination execution, and infrastructure still have costs. Production service pricing has not been established.

Both signers still check fresh control state. A policy requiring COMMIT+SESSION needs an exact on-chain approval as well. This legacy transfer-session path does not authorize RedPallas messages. Total spending budgets, EVM contract calls, and EVM simulation are not implemented.

Solidity integration is planned. Solana remains the sole authorization control plane; an EVM contract cannot currently replace the Solana controller.

Construct a bounded grant

Choose the enrolled account/path and supported destination adapter.
Bind the delegate credential, recipient, per-operation value limit, and validity interval.
For EVM native transfers, bind the enrolled backend-key digest, chain ID, gas-price cap, and total-fee cap.
Publish the grant with your controller wallet’s signature or through authenticated program CPI, and wait for finalized state.
Attach a proof of possession bound to the exact operation, current policy version, and session when requesting signing.

Both signers check authority before releasing output. Changing a request cannot broaden the registered grant. Policy versions advance by exactly one and invalidate old grants and proofs.

Compose policy requirements

COMMIT, SESSION, access proof, and constrained SIMULATE requirements come from registered policy. A caller cannot choose a weaker mode. When no applicable session replaces exact approval, COMMIT remains required.

The legacy Solana simulation adapter checks a tightly constrained native-transfer operation against a pinned immutable program. EVM SIMULATE and general-purpose destination-state predicates are not implemented.

Revoke or freeze

Have the controller account or program revoke the session, or freeze the namespace. The revocation is permanent for that grant ID; create a new ID for a replacement. Signers refuse future issuance after observing the updated state.

An already issued signature cannot be recalled. Grant limits are per operation, not a cumulative allowance. Do not treat a 0.01 ETH cap as a 0.01 ETH total budget.

Choose a flow to try

The live message demo illustrates exact approvals, independent signer checks and signature verification. The account and program quickstarts use your wallet and namespace. They do not demonstrate session expiry or revocation.

For native-transfer sessions, use the repository’s SDK integration and local test environment. Validate recipient mismatches, over-limit transfers, expiration and revoked grants before using a custom integration.