RBAC

Role-Based Access Control in Rising Tide Protocol - the five roles, how each is granted, and the entitlement verb catalog.

Rising Tide Protocol uses a Role-Based Access Control (RBAC) system. A user holds one or more roles; each role holds a flat set of entitlements; a user's effective set is the union. Roles do not inherit from each other.

The five roles

Role	How granted	Key permissions
`Member`	Automatically on first authentication	Participation: collect editions, RSVP events, submit predictions
`Open Beta`	Via an invite that attaches the role on claim. This is the role a waitlist approval attaches, so it is what a newcomer arrives with	Everything a Member can, plus `CREATE_PAGES` - drop bottles, write pages, publish letters
`Early Adopter`	Via an invite that attaches the role, or a manual grant	Everything a Member can, plus `CREATE_PAGES`. Kept as the tier new features land on first
`Artist`	Manual grant	Participation, plus `CREATE_ASSETS` - authoring and submitting stickers and style templates
`Admin`	Granted manually by the protocol team	Everything, including the operator entitlements (`VIEW_ADMIN_PANEL`, `MANAGE_ROLES`, `MANAGE_CONTRACTS`, `MANAGE_FUNDING_GROUPS`, ...)

Every new user starts as Member. Users cannot self-upgrade. Creation is what separates a creator from a collect-only Member: holding any CREATE_* entitlement. Artist is orthogonal to the tier ladder - it grants asset authoring without the product-deploy entitlements.

Who can mint an invite

Minting invites is derived from the creator's highest role tier, not from an entitlement, and during the alpha only an Admin (or the protocol itself) mints. Every other role's daily mint quota is zero:

Role	Daily mint quota
`Member`, `Open Beta`, `Early Adopter`	0
`Admin`	unlimited

Inviting is not gone for the other tiers - it moved. An Admin mints an invite and assigns it to a holder; the holder sends it. See Invites for the three parties on an invite.

Entitlement verbs

Verb prefix	Meaning
`CREATE_*`	Create new entities
`MANAGE_*`	Update or delete entities
`VIEW_*`	Read restricted data
`COLLECT_*`	Mint instances
`SUBMIT_*`	Submit predictions
`RSVP_*`	Reserve event tickets

RBAC vs feature flags

RBAC is the protocol security layer - enforced by the API, stored in the database.

Feature flags are your own per-deployment configuration - they control which UI features are visible in a given build of your app.

These are separate systems. A user's RBAC role does not automatically change any app's feature flags. A third axis, per-app access (whether a user may be in an app at all), is separate again - see the entry curtain on Providers.

Checking entitlements in your app

import { useProtocolUser } from "@rising-tide/ui/auth";

function MintButton() {
  const { hasEntitlement } = useProtocolUser();
  return hasEntitlement("COLLECT_EDITIONS") ? <button>Collect</button> : null;
}

useProtocolUser must be called inside RisingTideProviders (or the lower-level ProtocolUserProvider). See Auth Providers for setup.

Entitlements are enforced server-side by the protocol API on every user-acting route, so a client check is a UX affordance rather than the gate. A request that lacks the entitlement gets a 403 whatever the UI showed.

See Entitlements Reference for the full grants matrix.