Modern blockchains are built on cryptography, but not all of them treat permissions the same way. Most networks still rely on a simple model: one private key controls everything. This is easy to use but difficult to secure… especially for institutions, multi-user teams, and high-stakes environments.

XPR Network approaches permissions very differently.

Built on an EOSIO-based architecture, the network includes a native, multi-layered permissions system at the protocol level. This gives users, developers, and enterprises the ability to define granular authority, create custom roles, and implement secure multisig without relying on external tools or custom contract logic.

Why Permissions Matter

The moment multiple people or services need to interact with the same account or when an organization requires operational separation of duties, a single key model breaks down. Traditional EVM chains patch this gap with smart-contract-based access control (Ownable, AccessControl, timelocks, Gnosis Safe multisigs), but all of these are external constructs built on top of the chain, not core to it.

XPR Network builds permissions into the operating system of the chain itself.

This design offers three core advantages:

1. Native, secure multisig at the account level
   
   

2. Named, hierarchical permission levels tailored to each use case
   
   

3. Granular control over individual contract actions
   
   
   

Core Concepts

1. Named Permission Levels

Every account on XPR Network has at least two permission levels:

• owner – ultimate authority; used rarely
  
  

• active – general operational authority
  
  

But accounts can create any number of custom permissions such as:

• withdrawal_ops

  

• custody

  

• automation

  

• compliance_review

  

• oracle_signer

  

Each permission level can be linked to keys, accounts, or multisig structures.

2. Weighted Threshold Multisig

Permissions are defined using a threshold model:

• Each key or account has a weight
  
  

• Each permission level has a threshold
  
  

• A valid authorization is any combination of keys/accounts whose total weight meets or exceeds the threshold
  
  

Example:

{
  "perm_name": "withdrawal_ops",
  "required_auth": {
    "threshold": 2,
    "keys": [
      {"key": "PUB_K1...", "weight": 1},
      {"key": "PUB_K1...", "weight": 1}
    ],
    "accounts": []
  }
}

This means: two team members must approve a withdrawal.

3. Action-Level Permission Mapping

Smart contracts on XPR Network can assign a specific permission level to each action.

Example:

• token.transfer → requires active

  

• token.freeze → requires compliance_ops

  

• bank.withdraw → requires withdrawal_ops

  

This mapping ensures that internal operations follow strict security boundaries without modifying contract logic.

4. Key Rotation Without Contract Upgrades

Because permissions are part of the account itself, not encoded in the contract, rotating keys or updating thresholds never requires redeploying or upgrading a contract. This creates a safer, more maintainable system for:

• security audits
  
  

• incident response
  
  

• enterprise operational changes
  
  

• removing team members or updating roles

Why This Approach Is More Secure

Most blockchains treat account authority as a monolith. If someone gains access to a key, they effectively become the owner of the account.

On XPR Network:

• A compromised key may only grant access to one permission level, not the entire account
  
  

• The attacker still needs to meet the threshold
  
  

• Critical actions can be isolated to dedicated permission levels
  
  

• Sensitive permissions can be restricted to offline or hardware-secured keys
  
  

This structure significantly reduces the attack surface.

Comparing XPR Network to EVM-Chains

The difference is structural: XPR Network has an operating-system-level permissions model. EVM relies on patterns and tooling layered on top.

Real-World Use Cases

1. Institutional Custody

Banks and fintechs can:

• Create dedicated roles for withdrawals, freezing, minting, reconciliation
  
  

• Require 2–3 signatures for sensitive operations
  
  

• Delegate automation to separate permission levels safely
  
  

2. DeFi Protocol Safety

Protocols can isolate admin functions such as:

• parameter updates
  
  

• pausing contracts
  
  

• contract upgrades
  
  

Each can be protected by unique permission trees without custom Solidity-style access control.

3. Multi-user Teams

Companies can assign:

• marketing keys (1-of-1)
  
  

• operations keys (2-of-3)
  
  

• developer keys (1-of-1 for deployment)

and rotate them as staff changes.

4. Autonomous Services

Bots or cron-like automations can be given restricted permissions:

• allowed to execute claimrewards

  

• prohibited from executing withdraw

  

This minimizes risk from automation.

Why XPR Network’s Permission System Is a Competitive Advantage

XPR Network’s permission model is not an add-on, it is a foundational architectural choice. It delivers:

• enterprise-grade security
  
  

• developer flexibility
  
  

• safer automation
  
  

• fine-grained control
  
  

• reduced reliance on external tools
  
  

• real-world readiness
  
  

As the ecosystem grows – especially with increasing interest from regulated institutions , this system offers a more robust, maintainable, and intuitive way to secure on-chain activity.

Conclusion

XPR Network’s permission system stands out because it does something most blockchains never considered: it treats account authority as a first-class citizen of the protocol.

Where other networks rely on contracts, libraries, and external multisig wallets, XPR Network provides:

• customizable permission hierarchies
  
  

• native threshold multisig
  
  

• granular action-level authorization
  
  

• safe key rotation

This empowers everyone, from casual users to global enterprises – to build secure, adaptable, and highly controlled blockchain systems without unnecessary complexity.

Learn more about multisig in our knowledge base or in the explorer documentation.