How authorization works
The signature isn't proof you logged in once — it's proof you approved this exact action.
PTERI treats authorization differently from most systems. There's no roles table being checked against a permissions list at request time — the signature over the specific action is the authorization.
Bound intent
Take a payment as an example. The intent — amount, destination, network, any privacy parameters — is assembled into one payload, and your wallet signs that exact payload. The resulting signature proves three things at once: the action was genuinely authorized, its parameters weren't altered after the fact, and it can't be replayed as a different action later. Identity, intent, and authorization aren't three separate checks — they're bound into one cryptographic proof.
Step-up authorization for sensitive actions
Sensitive actions — role changes, payouts, deletions — always require a fresh challenge and a new signature at the moment of the action. There's no "already trusted" state that persists from an earlier login; a session being active doesn't by itself authorize a new sensitive action.
Admin and privileged access
Administrative authority is modeled as a wallet with a defined scope of permissions, rather than a separate role-based trust system layered on top. Every privileged action still requires its own signed intent from that wallet.