Governance, RBAC, and Multi-tenant Boundaries

Goldie is designed to support many issuers (tenants) on a shared protocol while maintaining strict isolation.

Two-layer authority model

The protocol uses two layers of permissions:

1. Platform-level roles (shared protocol controls)

   • Registry administration and shared configuration (where applicable)
   • Global policy configuration (where applicable)
   • Platform-level safety controls (deployment-dependent)

2. Token-level administration (issuer / token-scoped roles)

   • Issuer operations for a specific ecosystem
   • Token-level configuration, minting/burning, and operational controls (where enabled)

In the standard launchpad model, token ecosystem governance (including upgrades and emergency actions where enabled) is executed by issuer governance, typically via multisig.

Token RBAC (why it matters for large issuers)

Token RBAC is one of the major operational features of the platform.

Each token ecosystem has its own TokenAccessManager. That means an issuer can delegate responsibilities across many distinct participants without handing them full control of the ecosystem.

In large organizations, it is common to separate duties across teams and service providers. Token-scoped roles are designed to support patterns like:

• Multiple compliance operators across regions
• Separate treasury operations and finance controls
• Independent auditors / attestation publishers
• Distinct redemption operators vs token administrators

Examples of token-scoped participants

The exact role configuration is deployment-dependent, but a typical enterprise setup can include:

• Issuer governance / admin: retains TOKEN_ADMIN and delegates day-to-day tasks.
• Compliance officer(s): granted COMPLIANCE_ENFORCER to manage token-scoped eligibility actions where enabled.
• Treasury operations: granted TOKEN_TREASURY_MANAGER for token treasury actions.
• Fee controller: granted TOKEN_FEE_MANAGER to update token-level fees/premiums where enabled.
• Asset auditor / attestation publisher: granted ASSET_AUDITOR for backing-related attestations where enabled.
• Redemption operations: often handled by TOKEN_ADMIN by default; deployments can introduce a narrower dedicated role if finer separation is required.
• Emergency responder: granted TOKEN_PAUSER for time-critical pause actions where enabled.
• Upgrade operator: granted TOKEN_UPGRADER for upgrades where enabled (commonly with a delay / multi-approval governance process).

Example enterprise role split (token-scoped)

The token roles below are examples of how a large issuer might separate duties across many participants.

It is also normal for multiple addresses to hold the same role (for example multiple compliance operators across regions), while upgrades remain restricted to a small governance set.

What this enables

• Least privilege: each participant only receives the permissions required for their function.
• Multi-party operations: multiple addresses can hold the same role (for example multiple compliance operators).
• Auditability: role grants/revocations and privileged operations are visible on-chain.

How AccessManager-style RBAC works (mechanics)

Goldie uses OpenZeppelin’s AccessManagerUpgradeable pattern to make permissions:

• Function-level: specific contract functions can require specific roles (instead of “one admin can do everything”).
• Delegable: roles can have admins, so a TOKEN_ADMIN can grant/revoke operational roles without touching platform-scoped roles.
• Observable: role labels and changes are recorded on-chain and can be reviewed in explorers and monitoring systems.

At a high level, deployments configure three things:

1. Role IDs and role labels

   • Deployments label roles (for example TOKEN_ADMIN, COMPLIANCE_ENFORCER) to make on-chain role state readable.

2. Role admin hierarchy

   • Example pattern: TOKEN_ADMIN is set as the admin for operational roles like MINTER, BURNER, TOKEN_FEE_MANAGER, and ASSET_AUDITOR.
   • This creates a practical delegation workflow: governance holds TOKEN_ADMIN, then assigns roles to teams/service providers.

3. Per-function permissions

   • Contracts are configured so that sensitive functions require the appropriate role.
   • Example pattern: token minting functions require MINTER; token pause requires TOKEN_PAUSER; upgrades require TOKEN_UPGRADER.

Execution delay and scheduled operations (why they exist)

For institutional deployments, RBAC is not only about who can act — it is also about how quickly high-impact actions can be executed.

OpenZeppelin’s access manager model supports delayed execution for privileged operations:

• A role can be granted with an execution delay, meaning calls made under that role must be scheduled and can only execute after the delay window.
• High-impact actions (commonly upgrades and certain parameter changes) can therefore behave like a built-in timelock.

Why this matters:

• Operational safety: it creates time to detect a compromised key or a suspicious upgrade.
• Process integrity: it supports change-control expectations (review → schedule → execute).
• Transparency: scheduled operations are visible on-chain before they execute.

Typical pattern:

• Fast / emergency actions (pause) are usually immediate.
• High-impact actions (upgrades) are usually delayed and executed by issuer governance.

Extending RBAC (defining new roles)

Deployments can define additional roles when finer separation of duties is required.

Conceptually, adding a role is:

• Choose a new token-scoped role ID
• Assign an admin (who can grant/revoke it)
• Map that role to specific function(s)

This is how large issuers can evolve from “one admin does everything” into a mature operating model with clear, auditable responsibilities.

Why this matters

This design creates clear operational guarantees:

• An issuer can operate its own token ecosystem without gaining platform-wide authority.
• A platform operator can manage global integrity without being involved in routine issuer operations.

Governance expectations

For institutional deployments, high-privilege actions are controlled by multi-approval governance (e.g., multisig). This is a security boundary that reduces key-compromise impact.

Upgradeability (where enabled)

Upgrades are publicly auditable on-chain. In the standard model, upgrades require issuer governance approval and execution.

Emergency pause (where enabled)

Emergency pause exists to respond to critical bugs or unsafe conditions. In the standard model, pause/unpause is executed by issuer governance. Deployments may additionally enforce safeguards such as time-limited pauses.

Auditability

Role changes and privileged actions are observable on-chain. This enables periodic access reviews and external verification.

Diagrams

Governance & RBAC boundary (platform vs token)

Rendering diagram…

Token RBAC delegation (example)

Rendering diagram…