HYBRID DEVNET · PUBLIC EVIDENCE LIVEVerifiable infrastructure for value, markets, identity, and operational dataInspect the network
HYBRID-CHAIN
Governance & Approvals

Make approval explicit.
Keep authority accountable.

When a consequential change needs approval, a chat message is not enough. Give reviewers the same proposal, make the required authority explicit, and retain the decision against the version they actually reviewed. Governance connects that approval history to wallet and contract workflows without confusing approval with execution.

Reviewed changeWho approved this exact version?
  1. Proposal
  2. Eligible decisions
  3. Separate execution
Illustrative workflow · availability and access controls apply
A familiar challenge

A proposed change affects a shared resource. Different people have seen different versions, and nobody can show which decision authorized the next step.

A more useful way forward

Give reviewers one versioned proposal and inspect eligible decisions together. A recorded decision does not itself execute the change.

See a practical example ↓
Why it matters

Fewer ambiguous handoffs. Clearer decisions.

For treasury controllers, platform operators, and security reviewers.

One shared decision context

Let reviewers discuss the same intended change, supporting evidence, and current version.

A visible authority boundary

Separate visibility, eligibility to decide, and permission to execute instead of treating an admin label as universal authority.

A trail worth reviewing

Give an investigator a route from a proposal to the recorded decisions and the independently verified outcome.

Core capabilities

The capabilities behind the outcome.

Match these capabilities to your workflow. Enabled operations and access are confirmed during integration planning.

Proposal review

Bring a proposed change and its supporting context into a reviewable record. Give each participant a common starting point instead of forwarding disconnected messages.

Eligible decision makers

Check the role, scope, and current authority required for the operation. Being able to read a proposal does not make someone an eligible approver.

Version-bound decisions

Retain decisions against the version and policy they concern. Recheck applicability when the underlying proposal or authority changes.

Connected authority evidence

Follow the proposal into the relevant contract or wallet context. Distinguish the decision from any later preparation, signature, or finality record.

How Governance & Approvals works

From a proposed change to a traceable decision.

  1. 01
    Frame the change

    Identify the resource, intended operation, exact version, and supporting evidence. Confirm the proposal type is enabled for the deployment.

  2. 02
    Collect eligible decisions

    Review the current authority and decision policy. Record each eligible decision against the proposal it actually addresses.

  3. 03
    Hand off with evidence

    Pass the reviewed context to the owning workflow, which must separately authorize and perform its operation. Inspect the resulting state rather than inferring success from approval.

A practical example · illustrative

Review a change to contract authority.

A contract team proposes a new authority arrangement. Security and operations need to review the same frozen launch intent before preparation continues.

Scope
Identify the exact launch record and proposed authority change.
Review
Check eligible reviewers and decisions against the current version.
Confirm
Inspect the subsequent preparation or execution evidence separately.
What the team takes away

The team can explain the decision without mistaking it for a deployed change or a completed transaction.

Operation-scoped access

Plan your first deployment.

Start with documented proposal and decision operations available to your workspace. Confirm exact role and policy requirements in the live API contract. Safe-management and other planned operations are not implied to be available; a proposal or ceremony does not itself execute a transaction.

Before your first integration

  • Select one proposal type and agree eligible reviewers and the decision policy.
  • Test an ineligible actor and a changed proposal version before relying on approval history.
  • Verify that the receiving workflow still performs its own authorization and records its actual result.
Open the account workspace
Questions before you build

Governance & Approvals, explained.

Does approval move funds?

No. Signing, broadcasting, settlement, and customer authorization remain separately controlled. An approval record does not replace those checks.

Is this only for token-holder voting?

The product story is operational authority: proposals, eligible reviewers, and versioned decisions. Do not assume a token-voting model or arbitrary governance mechanism is supported.

Can every administrator approve every proposal?

No. Review eligibility is specific to the operation, role, resource, and current policy. Test those boundaries for the intended workflow.

What happens when a proposal changes?

A previous decision must not be assumed to authorize new content. Inspect the current version and applicable decision requirements before continuing.

What should we agree before starting a pilot?

Use the product-specific checklist above to define scope and acceptance tests. Ask the team to confirm the deployment environment, access, supported operations, integration responsibilities, support arrangements, and commercial terms. Availability labels are not a pricing quote or a service-level commitment.

Start with one useful result

Make it work for your team.

Bring your workflow. We’ll help identify the scope, access, and acceptance checks for a practical pilot.

Plan your pilot
Build the next part of your workflow

Connected products.

Start with Governance & Approvals. Review these adjacent capabilities when your requirements call for them.