Create account
Home › Features › Roles & Permissions
Features · least privilege, additive

Owner, admin, operator, developer, viewer

Five roles, ~50 granular permissions, no super-admin bypass

Operations initiates, finance approves, engineering holds API keys, auditors read. Signing power comes from holding a key share — never from a role checkbox — so access control and custody control reinforce each other instead of blurring.

Share the Trust, Guard the Keys

Create accountLive on testnet in an afternoon
Compare PlansIncluded in a plan, not an add-on
The problem

Most breaches are an over-permissioned insider, not a broken cipher

Digital-asset operations fail at the seam between people and keys: one account that can do everything, shared credentials, an auditor with write access because read-only was inconvenient. Vaultody ships five roles with additive permissions and no super-admin bypass — and signing power comes from holding a key share, never from a checkbox.

  • Read access is genuinely read-onlyA viewer sees the full picture and can sign nothing — the auditor seat with no attack surface.
  • Developers integrate without spendingAPI integration rights are separate from transfer rights, so an engineer can ship without being able to move funds.
  • Role changes are approval-gatedPromoting someone is a governed action, recorded like any other sensitive change.

How it works

Separation of duties, by default

Initiating and approving are different permissions; viewer sees everything and touches nothing. Roles are additive permission sets — no deny-override puzzles, no inherited surprises, and owner/admin are themselves permission-bound.

  • ✓Developer: API integration without transfer rights
  • ✓Viewer: complete read access, zero attack surface — built for auditors
  • ✓Role changes are approval-gated actions
team
A
Anna Petrova
owner · key share holder
signs
O
Ops team
operator · initiates
no approve
A
Auditor
viewer
read-only
Specification

The role model

Five roles, and the one nuance most vendors gloss over.

OwnerThe account's ultimate authority: billing, plan changes and the default approver on hard-coded sensitive actions.
AdminDay-to-day administration of team, keys and configuration, inside the approval rules.
OperatorCreates and manages transaction requests; cannot rewrite governance.
DeveloperAPI keys and integration surface; no transfer rights of its own.
ViewerFull read, zero write. Built for auditors and finance reviewers.
GranularityPermissions are granular and additive across the dashboard surface — roles compose rather than override.
Approval eligibilityHolding an approval permission makes a person selectable as an approver; the specific rule still has to name them.
Neither is a roleApprover and signer are not dashboard roles. Approving comes from a policy rule naming you; signing comes from holding a key share on your device.
Team capacityTwo seats on Entry, three on Standard, five on Business, negotiated on Enterprise.

Frequently asked questions

Get answers to commonly asked questions.

What happens when someone leaves?

Revoke the role; if they held a key share, run a reshare ceremony — key material never travels with people, and addresses never change.

Can we create custom roles?

The five roles with granular permissions cover the practical shapes; custom composition is an Enterprise conversation.

How many seats do plans include?

2 on Entry, 3 on Standard, 5 on Business, custom on Enterprise.

Share the Trust Guard the Keys

Access that maps to your org — least privilege without the admin pain.

Create accountRequest Demo