Introducing Role Templates

Role-based access controls (RBAC) are one of the most important parts of the Dfns platform. They define what each user or service account can do across wallets, keys, transactions, policies, and organization settings. In practice, they are how an organization enforces least-privilege access: every identity should have exactly the permissions it needs to perform its role, and nothing more. That principle is simple, but implementing it at scale is harder.

Dfns gives organizations fine-grained control over a broad range of operations. This is powerful, but it also means teams need to make many decisions when configuring access. Which permissions should a payment operator have? What should an auditor be allowed to see? Should a service account be able to create wallets? Should the same person who creates permissions also be able to assign them? What happens if only one administrator can manage policies?

These questions matter because access control is not just a configuration exercise. It is a security model. Permissions shape who can move funds, who can approve sensitive changes, who can create infrastructure, who can view audit trails, and who can govern the organization itself.

That is why we are introducing Role Templates. Role Templates are predefined permission groupings designed around common responsibilities found in financial institutions, fintechs, payment companies, trading firms, and digital asset teams. Instead of asking every organization to build access models from scratch, Role Templates provide a clear starting point for secure, auditable, and operationally practical access control.

They help teams move from individual permission management to functional role management. Rather than thinking only in technical terms, which API operations an identity can call, Role Templates help organizations think in operational terms: what responsibility does this person or service account hold inside the organization?

How Role Templates change the admin experience

Access control often fails in two ways.

1. Over-permissioning. A user or service account is given broad access because it is faster, easier, or because the team is not sure which specific permissions are required. This reduces friction in the short term, but it creates long-term risk. A compromised account, misconfigured integration, or internal mistake can have a much larger blast radius than necessary.
2. Under-permissioning. A user cannot complete a task, a service account cannot execute a workflow, or an approval path breaks because the right permission was missing. This creates delays, support tickets, and operational workarounds. In regulated environments, workarounds are rarely harmless. They often weaken the very controls the organization is trying to enforce.

Role Templates are designed to solve both problems. They give organizations a safe and understandable baseline. New users, service accounts, and integrations can be onboarded with clear access boundaries from day one. Security teams can see which identities map to which responsibilities. Operations teams can move faster without guessing which permissions are needed. Compliance and audit teams can review access in a way that maps to real roles, not just a long list of API actions.

The result is a cleaner access model: easier to configure, easier to explain, and easier to audit.

From programmatic permissions to practical roles

Dfns already provides granular permissions across the platform. Role Templates build on top of that foundation. A Role Template is a named set of permissions that reflects a common organizational function. For example, a payments operator may need access to execute transfers, view wallet balances, and monitor transaction status. That same person should not necessarily be able to modify organization settings, assign permissions, or change policy rules.

Similarly, an auditor may need broad visibility across wallets, transactions, policies, logs, staking activity, exchange operations, and service accounts. But that access should be read-only. The auditor’s job is to observe and verify, not to act or mutate. Role Templates encode these distinctions directly.

They are not meant to remove flexibility. Every organization has different workflows, risk models, and internal control requirements. Instead, Role Templates provide secure defaults and recommended structures that teams can adopt, adapt, and extend.

The four core role families

Role Templates are organized into four main families: Admin, Operator, Observer, and Integrator. 

Each family reflects a different type of responsibility inside an organization, and each is built around a clearly bounded set of capabilities.

Admin Roles

Admin Roles are for users responsible for platform governance. These roles cover the management of identities, service accounts, permissions, policies, and organization settings. 

The Admin family is built around five capability areas:

• User lifecycle management: create, update, deactivate, and delete users.
• Service account management: provision and maintain machine identities.
• Permission management: create, update, archive, assign, and revoke permissions.
• Policy management: create, update, and archive policies.
• Organization settings management: configure the platform at the org level.

Admin access is powerful by design, so it should be assigned carefully. We have introduced the following Admin Role Templates to our clients:

• User Administrator, which allows a user to manage human identities and their permissions without necessarily controlling policy or transaction permissions.
• Policy Administrator, which gives a user responsibility for creating and maintaining governance rules.

Admin Roles are about governance. They define who can shape the structure of the organization itself.

Operator Roles

Operator Roles are for users and service accounts responsible for day-to-day wallet, transaction, and key operations. 

The Operator family covers the action surface of the platform:

• Wallet management: create, update, and tag wallets.
• Transaction and transfer execution: initiate and broadcast on-chain activity.
• Key usage: sign, derive, and delegate.
• Exchange and payout operations: interact with connected venues and disbursement rails.
• Fee sponsor usage: make use of fee sponsorship workflows.

These identities need to act, but their access should remain scoped to operational activity. They should not automatically have administrative or policy management rights. As a starter, we have included the following Role to our client’s organizations:

• Wallet Manager, for users who create, update, tag, and maintain wallets.

If needed, you can always expand this role to support the management of transactions, staking operations, and other DeFi or Exchange-related actions.The purpose of Operator Roles is to support execution without giving operators control over the governance layer.

Observer Roles

Observer Roles are for users who need visibility but should not be able to make changes. This is essential for compliance teams, finance teams, auditors, risk teams, and external reviewers.

The Observer family is read-only by construction:

• Wallet and transaction read access
• Policy and permission read access
• Audit log and event read access
• Analytics and reporting access

We introduced to our client’s organizations the flagship Observer template: the Read-Only Auditor. It provides view-only access across the platform, including:

• Wallets:Read, Transactions:Read, Transfers:Read
• Authentication Logs:Read
• Users:Read, ServiceAccounts:Read
• Policies:Read, Approvals:Read
• Permissions:Read, Assignments:Read
• Staking:Read, Exchanges:Read, Fee Sponsors:Read
• Keys:Read, Signatures:Read
• Webhooks:Read, Events:Read

The use case is straightforward: a compliance officer or external auditor can inspect platform activity without creating operational risk. They can review what happened, when it happened, who performed the action, which policy applied, and how the organization is configured. No need to change anything.

Observer Roles make auditability practical. They let organizations share visibility without sharing control.

Integrator Roles

Integrator Roles are designed for machine identities. In modern financial infrastructure, many operations are performed by backend systems, automated workflows, monitoring agents, or external applications. These service accounts need permissions, but they should not be treated like human administrators.

The Integrator family follows three principles:

• Scoped to a single capability domain: for example, signing, webhooks, or staking.
• No administrative or organizational access: integrators do not govern the platform.
• Designed for machine identity, not human users: informing how rotation, expiry, and audit are handled.

We have provisioned our client’s organizations with the following Integrator Role Template:

• Developer Account, for general application-level automation.

Integrator Roles are especially important because service accounts are often long-lived and highly automated. Some good examples include provisioning Webhooks, Keys or Delegated Wallets. Other roles could be used to provide third parties scoped read-access to your organization for better debugging. They should have narrow permissions, clear scope, and strong governance around expiry, rotation, and usage.

Role clarity and configuration safety

The first benefit of Role Templates is clarity. When organizations configure permissions one by one, it can become difficult to understand the actual access model. A user may have many permissions across different parts of the platform. A service account may accumulate rights over time. A team may not remember why a permission was assigned in the first place.

Role Templates make access easier to understand. Instead of asking, “Why does this identity have these 37 permissions?”, teams can ask, “What role does this identity perform?” That shift matters. It creates a language that security, operations, compliance, and engineering teams can all understand. An Admin governs. An Operator executes. An Observer reviews. An Integrator automates. This makes access patterns visible, auditable, and easier to communicate across teams.

Confidence in least privilege by default

The second benefit is confidence. Good access control is not only about assigning permissions. It is also about knowing whether the organization is configured safely. Role Templates give Dfns a foundation for access review and recommendations against three core invariants:

1. Every identity is scoped. All users and service accounts in the organization have at least one permission assigned, and none operate with implicit or unscoped access.
2. No identity holds more than its role requires. This applies especially to sensitive operations such as Permissions:Assign, Permissions:Update, and Policies:Update.
3. Critical operations are gated by intent. Sensitive actions sit behind intentional, named permission assignments rather than inherited or default access.

By screening existing permission assignments against these invariants and a library of recommended patterns, Dfns can produce a posture score for the organization’s owner — a single, reviewable signal of how consistently least-privilege principles are being applied.

The kinds of issues we want to surface with that score include:

• A service account with Wallets:Create but no scoping policy restricting where it can create wallets.
• The absence of any identity holding Policies:Approvals:Approve, leaving policy changes with no approval path.
• An Admin-level permission assigned to a service account with no expiry or rotation signal.
• All permission management operations (assign, revoke, update) concentrated in a single user, with no separation of duties.
• Any user or service account operating without an explicit permission assignment.

Think of it as a brew doctor for your Dfns organization. In the same way AWS warns users about relying on a root email to access their accounts, Dfns can flag weak access control configurations before they become incidents, and point to the Role Templates that fix them.

Faster setup, quicker deployments

The third benefit is speed. When a new organization starts using Dfns, it should not need to become an expert in every permission before launching its first workflow. Teams should be able to start with secure defaults, assign the right Role Templates, and then adjust as their operating model becomes more specific.

The workflow is simple. A user with ManagedFullAdminAccess opens the Permissions section and finds the four families (Admin, Operator, Observer, and Integrator) laid out as ready-to-deploy templates. From there, an organization can bootstrap with at least two Admins, create a default Operator role for wallet and transaction operations, define a read-only Auditor role, and assign scoped Integrator roles to its backend systems.

That is enough to start operating with structure instead of improvisation. This is especially useful for institutions where access control must be reviewed internally before going live. Role Templates give security and compliance teams a clear framework to evaluate, instead of a raw list of technical permissions.

A more robust model for fintechs and institutions

Digital asset operations are becoming more complex. Institutions are no longer just creating wallets or sending occasional transactions. They are building payments products, trading systems, custody workflows, staking services, tokenization platforms, treasury operations, and embedded financial applications. As these use cases grow, access control becomes more important.

A wallet infrastructure platform must do more than secure keys. It must help institutions govern how those keys are used. It must define who can create wallets, who can move assets, who can approve sensitive changes, who can inspect activity, and which systems can automate specific workflows.

Role Templates are part of that broader governance model. They help organizations build access structures that look more like institutional finance: clear roles, explicit responsibilities, separation of duties, auditable activity, and controlled execution.

We’ll roll out this feature to all our clients, but these Roles will not overwrite any existing permissions or automatically assign them to any users. They will be used both as a baseline for simpler use cases and a template for more complex configurations.

Next: mapping templates to compliance standards

Most of the institutions building on Dfns operate inside formal control frameworks: ISO/IEC 27001, SOC 1 and SOC 2, ISAE 3402, and a growing set of region- and sector-specific standards. Each of these frameworks has something to say about access control: separation of duties, least privilege, privileged user management, periodic access reviews, evidence of authorization for sensitive operations. Role Templates are a natural place to encode that mapping, and it is a direction we plan to invest in.

On the roadmap, each Role Template will carry a set of compliance tags indicating which controls it helps satisfy and under which standard. A template like “Permission Manager Separation,” for example, would be tagged against the segregation-of-duties controls in SOC 2 and ISO/IEC 27001. “Read-Only Auditor” would map to access-review and audit-evidence controls. “Admin Bootstrap” would map to the controls covering single points of failure in privileged access management.

We expect this to deliver value on two sides:

• For the organization deploying templates, tags make the link between technical configuration and compliance posture explicit. When a security or compliance lead reviews access, the template’s tags answer the question "which control does this satisfy?" without a separate mapping exercise.
• For auditors and external reviewers, tagged templates provide a cleaner trail of evidence. Instead of reconstructing the intent behind a permission set, an auditor can see the named role, the controls it is designed to satisfy, and the assignments tied to it.

Over time, the same compliance metadata will feed into the posture score described above, flagging not only generic least-privilege issues, but also the specific control gaps that matter for a given certification or attestation an organization is pursuing.

We will share more as this work lands. For institutions already preparing for an upcoming audit, Role Templates are designed to be a foundation that compliance metadata can plug into directly when it ships.

With Role Templates, Dfns organizations can start from secure defaults, adapt them to their internal workflows, and maintain a clearer, more auditable permission model as they scale.

Get started with Dfns today: app.dfns.io