Data Model

Carabaas uses a hierarchical model that separates governance, security boundaries, and operational organization. The goal is to let teams model how their business operates without compromising security isolation.

Hierarchy

Organization                          ← governance & access boundary
│
├── Vault: Treasury                   ← MPC key, approval quorum
│   ├── Account: Operating            ← logical grouping (unique name within vault)
│   │   ├── Bitcoin Address 1
│   │   ├── Bitcoin Address 2
│   │   └── Ethereum Address 1
│   └── Account: Reserves
│       ├── Ethereum Address 2
│       └── Polygon Address 1
│
├── Vault: Client Deposits            ← separate MPC key, separate quorum
│   ├── Account: Customer A
│   │   └── @eth-like Address
│   └── Account: Customer B
│       ├── Bitcoin Address
│       └── Solana Address
│
└── Vault: DeFi Operations
    └── Account: Strategy 1
        ├── Ethereum Address
        └── Arbitrum Address

Organization

An organization is the top-level boundary where users, clients, and permissions are defined. In most deployments, an organization maps to a single legal or operational business entity (e.g., a company or business unit).

If a single customer operates multiple independent entities (for example, a corporate group with several subsidiaries), you can create multiple organizations — each with isolated vaults, accounts, addresses, and access policies.

Organization-Level Roles

Role	Abilities
OrgAdmin	read, edit, inviteUser, removeUser, assignRole, suspendUser, manageClients, viewAudit, manageVaults, manageAddressBook, viewClients
SecurityOfficer	read, suspendUser, manageClients, viewAudit, suspendVaults, viewClients
User	read
HostedSigner	sign
ManagedSigner	sign
SharedSigner	sign

Vault

A vault is a security and governance boundary backed by its own MPC key material and access control. Each vault has an independent set of signing permissions and approval rules, so you can segment funds and operations according to your internal processes and risk model.

Typical vault separation patterns:

• Processing / hot operations — high-frequency withdrawals and operational transfers
• Customer funds — segregated custody for client assets with stricter approval policies
• Treasury / corporate funds — company-owned funds with finance-led controls
• Staking / DeFi operations — vaults dedicated to strategy-specific workflows

Vault-Level Roles

Role	Abilities
VaultAdmin	read, generateDetails, initiate, edit, assignRole, suspend, viewAudit, approve, decline, manageAddressBook, viewClients, manageNotifications
Treasurer	read, generateDetails, initiate, approve, decline, manageAddressBook, viewClients, manageNotifications
Operator	read, generateDetails, initiate, viewClients
Approver	read, generateDetails, approve, decline, viewClients
Viewer	read

Vault States

Status	Description
pending	Vault is being set up, MPC key generation in progress
active	Vault is ready for use
suspended	Operations temporarily disabled
inactive	Vault is archived

Account

Accounts are an organizational layer inside a vault. They do not create a new cryptographic boundary; instead, they help structure operations and reporting within the same vault.

Account names must be unique within a vault.

The simplest setup is a single account and as many addresses as you need. More advanced setups use accounts to reflect real-world operational structure:

• Per-customer processing — an exchange or payments processor creates one account per customer and generates deposit addresses inside that account
• Operational buckets — separate accounts for collection, transit, and settlement flows
• Departmental organization — finance, ops, and risk teams operate distinct accounts with different workflows

Address

Addresses are the on-chain endpoints used to receive deposits and send funds. They are blockchain-specific and generated from the vault's master key using HD derivation (BIP-44 with soft derivation).

You can create unlimited addresses per account for any supported blockchain. Each address name must be unique within its account.

Addresses are where operational work happens — deposit attribution, customer accounting, reconciliation — while accounts provide structure and vaults provide security isolation and governance.

ETH-Like Universal Addresses

Use network @eth-like to generate a single address that works across all EVM-compatible chains — Ethereum, Polygon, BSC, Arbitrum, Optimism, Avalanche, and more. New EVM networks are automatically supported.

tip

Universal EVM addresses are ideal for multi-chain payment acceptance and treasury management — one address, all EVM chains.