Skip to main content

Authority model

Kurabase deliberately separates instance delegation, user identity, and relational policy evaluation.

Instance delegation​

The developer who creates an instance explicitly grants one or more gateways permission to act for that instance. This is a contract-level delegation. A gateway that is not granted has no path around it.

The contract checks delegation, gateway epoch, expiry, session binding, and revocation. The owner can grant more than one gateway and can revoke a gateway without implying that another gateway has authority.

User authorization​

A user signs in through a self-signed wallet session or an instance-configured identity authority. The resulting envelope proves caller identity for a delegated gateway. The gateway exchanges it for a scoped bearer token, but does not generate authority on the user's behalf.

The consequence is intentional:

  • A user session alone does not authorize an undelegated gateway.
  • A delegated gateway alone does not create a user session.
  • A delegated gateway uses a valid user session to evaluate an allowed write.

Account-abstraction execution​

For production application writes, Privy owns authentication and the account owner: a connected external wallet stays the owner, while social login uses a Privy embedded wallet. The gateway signs a short-lived, exact write plan only after identity and RLS checks. The named Privy/ZeroDev account submits it. The contract rejects a plan unless msg.sender is that account, so a gateway's attestation key cannot submit a user write itself.

The optional gateway credential is a user-approved ZeroDev session key scoped to this instance, the executeGatewayPlan selector, no ETH value, rate/value limits and a short expiry. It is not a gateway wallet private key, cannot move assets or manage the instance, and must be stored in KMS/HSM infrastructure. See Privy and account abstraction for the complete flow.

Instance operator and Dashboard management​

For a local kura start instance, bootstrap provisions an instance-held operator and delegates its privileged gateway. Studio serves a same-origin proxy that holds the generated dev-server credential inside the local Compose network. The Dashboard receives only the public instance address and can run local SQL and migrations without a browser wallet or server-key field.

This is intentionally a local development management identity, not a user identity. The proxy is loopback-only, and its service credential can bypass RLS through the privileged gateway. It must never be bundled into browser code or deployed as a public proxy.

For a remote instance, the Dashboard retains an owner/developer-signed distinct EIP-712 AdminSession through an EIP-1193 wallet such as an injected wallet or WalletConnect provider.

An AdminSession is valid only for a privileged delegated gateway, a current owner or developer, the current gateway epoch, and the current administrator epoch. It is a different typed-data signature from a normal user session, so a normal RLS sign-in cannot be replayed as schema-management approval. An identity authority can attest a user session, but it cannot become an administrator.

The gateway produces a signing intent and submits the wallet-approved remote plan. It cannot mint user authority. Local instances that predate the contract feature report walletManagementSupported: false; Dashboard management explains the explicit redeploy path instead of trying an unsafe browser-key fallback.

RLS boundary​

RLS, relational constraints, and SQL-language function semantics execute in the explicitly delegated gateway. This gateway is a trusted executor for those semantics. The contract does not prove that arbitrary SQL was evaluated correctly or that a table policy was correctly interpreted.

Do not describe this system as trustless SQL execution. It provides explicit delegation and cryptographic user identity, with gateway-enforced relational rules.

Secrets and public data​

Public-chain data is not confidential. Do not store personal data, access tokens, private keys, or conventional secret records in chain-backed state. Encryption, key management, and metadata leakage require separate design work.