Core Concepts
Understand the key domain concepts you'll work with when building on Cubewire Wallet-as-a-Service.
Organization
An Organization is the top-level entity representing your company or business. All resources—vaults, users, policies, and configurations—are scoped to an organization.
| Property | Description |
|---|---|
| ID | Unique identifier for the organization |
| Name | Display name of the organization |
| Slug | URL-friendly unique identifier |
| Environment | PRODUCTION or DEVELOPMENT |
Multi-Organization Support
Users can belong to multiple organizations and switch between them. This is useful for agencies managing multiple clients or businesses with separate entities.
Environment Types
| Environment | Description |
|---|---|
| PRODUCTION | Live environment with real assets |
| DEVELOPMENT | Testing environment with test assets |
Environment Isolation
Production and development environments are fully isolated. API credentials, vaults, and data do not cross environment boundaries.
Vault
A Vault is a secure wallet with its own blockchain address. Each vault has cryptographic keys stored in HSM infrastructure—you interact with vaults through our API, and we handle all the key management.
| Property | Description |
|---|---|
| ID | Unique identifier for the vault |
| Name | Display name you assign |
| Address | Blockchain address for receiving and sending assets |
| Status | active or inactive |
What You Can Do With Vaults
- Send transactions — Transfer native currency or tokens
- Receive assets — Each vault has a unique address across supported networks
- Track balances — View assets held in the vault
- Apply policies — Attach spending limits and approval rules
Multi-Chain Support
A single vault address works across all supported EVM networks. Send ETH on Ethereum, MATIC on Polygon, or tokens on any supported chain—all from the same address.
Transaction
A Transaction represents a blockchain operation initiated through Cubewire. When you submit a transaction, we evaluate policies, perform compliance checks, sign with HSM-protected keys, and broadcast to the blockchain.
Transaction Types
| Type | Description |
|---|---|
| TRANSFER | Send native currency or ERC-20 tokens |
| CONTRACT_CALL | Execute a smart contract function |
| CONTRACT_DEPLOY | Deploy a new smart contract |
| TYPED_MESSAGE | Sign EIP-712 structured data |
Transaction Statuses
| Status | Description |
|---|---|
| PENDING_APPROVAL | Waiting for required approvals |
| APPROVED | Approvals received, processing |
| SUBMITTED | Signed and broadcast to blockchain |
| CONFIRMED | Included in a confirmed block |
| FAILED | Transaction execution failed |
| REJECTED | Approval request was rejected |
| CANCELLED | Cancelled before execution |
Policy
A Policy is a rule that evaluates transactions and determines what action to take. Policies let you define spending limits, address allowlists, time-based restrictions, and multi-party approvals.
| Property | Description |
|---|---|
| Name | Descriptive name for the policy |
| Priority | Evaluation order (lower = evaluated first) |
| Status | ACTIVE, INACTIVE, or DRAFT |
| Conditions | Rules that must match for the policy to apply |
| Action | What happens when conditions match |
Policy Actions
| Action | Description |
|---|---|
| ALLOW | Transaction proceeds without additional checks |
| BLOCK | Transaction is rejected |
| REQUIRE_APPROVAL | Transaction requires human approval before proceeding |
| NOTIFY | Send notification but allow transaction |
Example Policies
| Use Case | Conditions | Action |
|---|---|---|
| Spending limit | Amount > $10,000 | Require approval |
| Address allowlist | Recipient not in trusted list | Block |
| High-value review | Amount > $50,000 | Require 2 approvals |
Policy Evaluation
Policies are evaluated in priority order. The first matching policy determines the action. If no policy matches, the transaction is allowed by default.
Named List
A Named List is a reusable collection of values that policies can reference. Use lists for address allowlists, blocklists, and approver groups.
| Property | Description |
|---|---|
| Name | Unique name within your organization |
| Type | ADDRESS, COUNTRY_CODE, or custom |
| Items | Array of values in the list |
Common Use Cases
| List Type | Example Use |
|---|---|
| Address allowlist | Trusted withdrawal addresses |
| Address blocklist | Known risky addresses |
| Approved assets | Tokens allowed for trading |
| Approver group | Users who can approve high-value transactions |
Approval
When a policy requires approval, a Transaction Approval Request is created. Designated approvers can vote to approve or reject the transaction.
| Property | Description |
|---|---|
| Status | PENDING, APPROVED, REJECTED, or EXPIRED |
| Required Approvers | Number of approvals needed |
| Deadline | When the request expires |
| Votes | Individual approver decisions |
Approval Flow
Webhook
A Webhook delivers real-time notifications to your systems when events occur. No polling required—we push updates to your endpoint as they happen.
| Property | Description |
|---|---|
| URL | Your endpoint to receive webhook payloads |
| Events | Event types you're subscribed to |
| Secret | HMAC key for verifying payload signatures |
Webhook Events
| Event | Description |
|---|---|
transaction.submitted | Transaction broadcast to blockchain |
transaction.confirmed | Transaction confirmed on-chain |
transaction.failed | Transaction execution failed |
transaction.approval_required | Transaction needs approval |
vault.created | New vault created |
inbound.detected | Incoming transfer detected |
Webhook Security
All webhook payloads include an HMAC signature in the X-Cubewire-Signature header. Always verify signatures before processing webhooks.
User & Role
User
A User is an individual who can access your organization in Cubewire—either through the dashboard or as an approver for transactions.
| Property | Description |
|---|---|
| Unique email address | |
| Status | Account status |
| Roles | Assigned roles determining permissions |
Role
A Role is a collection of permissions assigned to users. Cubewire provides system roles, and you can create custom roles.
System Roles
| Role | Description |
|---|---|
| Owner | Full administrative access |
| Admin | Administrative access without billing |
| Member | Standard user access |
| Viewer | Read-only access |
Permissions
Permissions follow the format resource:action. Common examples:
| Permission | Description |
|---|---|
vaults:create | Create new vaults |
vaults:send | Send transactions from vaults |
transactions:approve | Approve pending transactions |
policies:update | Modify policies |
Network
A Network is a supported blockchain where you can send transactions and hold assets.
Supported Networks
| Network | Chain ID | Type |
|---|---|---|
| Ethereum | 1 | Mainnet |
| Polygon | 137 | Mainnet |
| Arbitrum One | 42161 | Mainnet |
| Base | 8453 | Mainnet |
| Ethereum Sepolia | 11155111 | Testnet |
| Polygon Amoy | 80002 | Testnet |
| Cubewire Testnet | 62831 | Testnet |
Development
Start with Cubewire Testnet for development—it's fast, free, and purpose-built for testing. Use the Cubewire Faucet to get test tokens.
API Authentication
Cubewire uses OAuth 2.0 client credentials for API authentication.
| Component | Description |
|---|---|
| Client ID | Public identifier for your API credential |
| Client Secret | Secret key (store securely, never expose in client-side code) |
| Access Token | Short-lived JWT for API requests (1 hour TTL) |
Compliance
Cubewire includes built-in compliance checks that run automatically on transactions.
| Check | Description | When Applied |
|---|---|---|
| AML/KYT | Transaction monitoring for money laundering risk | Every outbound transaction |
| Sanctions | Screening against OFAC, UN, EU sanctions lists | Every transaction |
| Travel Rule | Originator/beneficiary data exchange per FATF guidelines | Transfers above threshold |
Configuration
Compliance settings are configured at the organization level. Contact your account manager to customize compliance checks for your use case.
Next
- Onboarding — Create your account and set up an organization
- Authentication — Set up console and API access
Core Concepts
Understand the key domain concepts you'll work with when building on Cubewire Wallet-as-a-Service.
Organization
An Organization is the top-level entity representing your company or business. All resources—vaults, users, policies, and configurations—are scoped to an organization.
| Property | Description |
|---|---|
| ID | Unique identifier for the organization |
| Name | Display name of the organization |
| Slug | URL-friendly unique identifier |
| Environment | PRODUCTION or DEVELOPMENT |
Multi-Organization Support
Users can belong to multiple organizations and switch between them. This is useful for agencies managing multiple clients or businesses with separate entities.
Environment Types
| Environment | Description |
|---|---|
| PRODUCTION | Live environment with real assets |
| DEVELOPMENT | Testing environment with test assets |
Environment Isolation
Production and development environments are fully isolated. API credentials, vaults, and data do not cross environment boundaries.
Vault
A Vault is a secure wallet with its own blockchain address. Each vault has cryptographic keys stored in HSM infrastructure—you interact with vaults through our API, and we handle all the key management.
| Property | Description |
|---|---|
| ID | Unique identifier for the vault |
| Name | Display name you assign |
| Address | Blockchain address for receiving and sending assets |
| Status | active or inactive |
What You Can Do With Vaults
- Send transactions — Transfer native currency or tokens
- Receive assets — Each vault has a unique address across supported networks
- Track balances — View assets held in the vault
- Apply policies — Attach spending limits and approval rules
Multi-Chain Support
A single vault address works across all supported EVM networks. Send ETH on Ethereum, MATIC on Polygon, or tokens on any supported chain—all from the same address.
Transaction
A Transaction represents a blockchain operation initiated through Cubewire. When you submit a transaction, we evaluate policies, perform compliance checks, sign with HSM-protected keys, and broadcast to the blockchain.
Transaction Types
| Type | Description |
|---|---|
| TRANSFER | Send native currency or ERC-20 tokens |
| CONTRACT_CALL | Execute a smart contract function |
| CONTRACT_DEPLOY | Deploy a new smart contract |
| TYPED_MESSAGE | Sign EIP-712 structured data |
Transaction Statuses
| Status | Description |
|---|---|
| PENDING_APPROVAL | Waiting for required approvals |
| APPROVED | Approvals received, processing |
| SUBMITTED | Signed and broadcast to blockchain |
| CONFIRMED | Included in a confirmed block |
| FAILED | Transaction execution failed |
| REJECTED | Approval request was rejected |
| CANCELLED | Cancelled before execution |
Policy
A Policy is a rule that evaluates transactions and determines what action to take. Policies let you define spending limits, address allowlists, time-based restrictions, and multi-party approvals.
| Property | Description |
|---|---|
| Name | Descriptive name for the policy |
| Priority | Evaluation order (lower = evaluated first) |
| Status | ACTIVE, INACTIVE, or DRAFT |
| Conditions | Rules that must match for the policy to apply |
| Action | What happens when conditions match |
Policy Actions
| Action | Description |
|---|---|
| ALLOW | Transaction proceeds without additional checks |
| BLOCK | Transaction is rejected |
| REQUIRE_APPROVAL | Transaction requires human approval before proceeding |
| NOTIFY | Send notification but allow transaction |
Example Policies
| Use Case | Conditions | Action |
|---|---|---|
| Spending limit | Amount > $10,000 | Require approval |
| Address allowlist | Recipient not in trusted list | Block |
| High-value review | Amount > $50,000 | Require 2 approvals |
Policy Evaluation
Policies are evaluated in priority order. The first matching policy determines the action. If no policy matches, the transaction is allowed by default.
Named List
A Named List is a reusable collection of values that policies can reference. Use lists for address allowlists, blocklists, and approver groups.
| Property | Description |
|---|---|
| Name | Unique name within your organization |
| Type | ADDRESS, COUNTRY_CODE, or custom |
| Items | Array of values in the list |
Common Use Cases
| List Type | Example Use |
|---|---|
| Address allowlist | Trusted withdrawal addresses |
| Address blocklist | Known risky addresses |
| Approved assets | Tokens allowed for trading |
| Approver group | Users who can approve high-value transactions |
Approval
When a policy requires approval, a Transaction Approval Request is created. Designated approvers can vote to approve or reject the transaction.
| Property | Description |
|---|---|
| Status | PENDING, APPROVED, REJECTED, or EXPIRED |
| Required Approvers | Number of approvals needed |
| Deadline | When the request expires |
| Votes | Individual approver decisions |
Approval Flow
Webhook
A Webhook delivers real-time notifications to your systems when events occur. No polling required—we push updates to your endpoint as they happen.
| Property | Description |
|---|---|
| URL | Your endpoint to receive webhook payloads |
| Events | Event types you're subscribed to |
| Secret | HMAC key for verifying payload signatures |
Webhook Events
| Event | Description |
|---|---|
transaction.submitted | Transaction broadcast to blockchain |
transaction.confirmed | Transaction confirmed on-chain |
transaction.failed | Transaction execution failed |
transaction.approval_required | Transaction needs approval |
vault.created | New vault created |
inbound.detected | Incoming transfer detected |
Webhook Security
All webhook payloads include an HMAC signature in the X-Cubewire-Signature header. Always verify signatures before processing webhooks.
User & Role
User
A User is an individual who can access your organization in Cubewire—either through the dashboard or as an approver for transactions.
| Property | Description |
|---|---|
| Unique email address | |
| Status | Account status |
| Roles | Assigned roles determining permissions |
Role
A Role is a collection of permissions assigned to users. Cubewire provides system roles, and you can create custom roles.
System Roles
| Role | Description |
|---|---|
| Owner | Full administrative access |
| Admin | Administrative access without billing |
| Member | Standard user access |
| Viewer | Read-only access |
Permissions
Permissions follow the format resource:action. Common examples:
| Permission | Description |
|---|---|
vaults:create | Create new vaults |
vaults:send | Send transactions from vaults |
transactions:approve | Approve pending transactions |
policies:update | Modify policies |
Network
A Network is a supported blockchain where you can send transactions and hold assets.
Supported Networks
| Network | Chain ID | Type |
|---|---|---|
| Ethereum | 1 | Mainnet |
| Polygon | 137 | Mainnet |
| Arbitrum One | 42161 | Mainnet |
| Base | 8453 | Mainnet |
| Ethereum Sepolia | 11155111 | Testnet |
| Polygon Amoy | 80002 | Testnet |
| Cubewire Testnet | 62831 | Testnet |
Development
Start with Cubewire Testnet for development—it's fast, free, and purpose-built for testing. Use the Cubewire Faucet to get test tokens.
API Authentication
Cubewire uses OAuth 2.0 client credentials for API authentication.
| Component | Description |
|---|---|
| Client ID | Public identifier for your API credential |
| Client Secret | Secret key (store securely, never expose in client-side code) |
| Access Token | Short-lived JWT for API requests (1 hour TTL) |
Compliance
Cubewire includes built-in compliance checks that run automatically on transactions.
| Check | Description | When Applied |
|---|---|---|
| AML/KYT | Transaction monitoring for money laundering risk | Every outbound transaction |
| Sanctions | Screening against OFAC, UN, EU sanctions lists | Every transaction |
| Travel Rule | Originator/beneficiary data exchange per FATF guidelines | Transfers above threshold |
Configuration
Compliance settings are configured at the organization level. Contact your account manager to customize compliance checks for your use case.
Next
- Onboarding — Create your account and set up an organization
- Authentication — Set up console and API access