Keys & authorizations

This page explains the keys that can write data under your wallet, where those grants live, and how to review or revoke them.

Prerequisite: signed in. Background: Your data on Aleph.

Why other keys write under your wallet

Your project data lives on Aleph under your wallet address — but you wouldn't want to approve a wallet popup for every status change of every deploy. So Aleph supports delegation: your wallet signs, once, a security record listing other keys allowed to write specific kinds of messages on your behalf. Everything in that record is public and auditable.

Three keys are involved:

Key	Held by	What it's for
Your wallet	You	The owner. Signs the grants below; the only key that can change them.
Browser session key	Your browser	Signs your own writes (creating projects, saving settings) without a wallet popup each time. Rotates on a 24-hour cycle; a new one is created and the old one revoked automatically as you use the app.
Stasho delegate	Our backend	Writes deployment progress (queued → building → live) and pins artifacts as your builds run — the writes that happen while your browser is closed.

The grants are scoped: the delegate and session keys can write project and deployment records only. Neither can touch the security record itself — so a leaked session key can forge deploy statuses for a day at worst, never lock you out or grant itself more power.

The Authorizations tab

Settings → Authorizations lists every key currently (or previously) authorized under your wallet:

• Aleph Cloud — the Stasho delegate
• This browser — your active session key
• Expired or other-device session keys, awaiting cleanup or still active elsewhere

Each row shows what the key may write and offers Revoke.

Revoking

Revoke a session key any time — for instance one from a device you've lost. Your next write bundles the removal into the on-chain record.

Revoke the Stasho delegate and deploys stop working: builds can't report status and artifacts can't be pinned. The deployment that hits the wall shows Re-authorization required (awaiting_resign), and the Redeploy button becomes Re-authorize. This is reversible — re-authorizing is one wallet signature, and the next deploy proceeds.

The same Re-authorization required state can appear without you revoking anything — e.g. when the app needs a grant that didn't exist when you first signed up (this happened to alpha users when custom domains shipped). The fix is the same single signature in Settings → Authorizations.

Verification

• The Authorizations tab shows the delegate and your current browser, both marked authorized
• The same list, from outside the app: https://api.stasho.xyz/api/audit/<your-address> — or on-chain via any Aleph explorer
• After a revoke + re-authorize cycle, a Redeploy completes normally

What can go wrong

Symptom	Cause	Fix
Deployment stuck at "Re-authorization required"	The delegate lacks a grant (revoked, or a newer feature needs more scope)	Settings → Authorizations → sign the re-authorize prompt → Redeploy
Authorizations tab shows a browser you don't recognize	A session key from another device or browser profile of yours — or not	Revoke it; sessions elsewhere will just re-prompt to sign in