Understand the key domain concepts you'll work with when building on Cubewire Wallet-as-a-Service.
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 |
Users can belong to multiple organizations and switch between them. This is useful for agencies managing multiple clients or businesses with separate entities.
| Environment | Description |
|---|---|
| PRODUCTION | Live environment with real assets |
| DEVELOPMENT | Testing environment with test assets |
Production and development environments are fully isolated. API credentials, vaults, and data do not cross environment boundaries.
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 |
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.
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.
| 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 |
| 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 |
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 |
| 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 |
| 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 |
Policies are evaluated in priority order. The first matching policy determines the action. If no policy matches, the transaction is allowed by default.
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 |
| 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 |
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 |
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 |
| 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 |
All webhook payloads include an HMAC signature in the X-Cubewire-Signature header. Always verify signatures before processing webhooks.
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 |
A Role is a collection of permissions assigned to users. Cubewire provides system roles, and you can create custom roles.
| Role | Description |
|---|---|
| Owner | Full administrative access |
| Admin | Administrative access without billing |
| Member | Standard user access |
| Viewer | Read-only access |
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 |
A Network is a supported blockchain where you can send transactions and hold assets.
| 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 |
Start with Cubewire Testnet for development—it's fast, free, and purpose-built for testing. Use the Cubewire Faucet to get test tokens.
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) |
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 |
Compliance settings are configured at the organization level. Contact your account manager to customize compliance checks for your use case.
Understand the key domain concepts you'll work with when building on Cubewire Wallet-as-a-Service.
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 |
Users can belong to multiple organizations and switch between them. This is useful for agencies managing multiple clients or businesses with separate entities.
| Environment | Description |
|---|---|
| PRODUCTION | Live environment with real assets |
| DEVELOPMENT | Testing environment with test assets |
Production and development environments are fully isolated. API credentials, vaults, and data do not cross environment boundaries.
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 |
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.
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.
| 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 |
| 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 |
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 |
| 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 |
| 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 |
Policies are evaluated in priority order. The first matching policy determines the action. If no policy matches, the transaction is allowed by default.
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 |
| 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 |
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 |
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 |
| 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 |
All webhook payloads include an HMAC signature in the X-Cubewire-Signature header. Always verify signatures before processing webhooks.
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 |
A Role is a collection of permissions assigned to users. Cubewire provides system roles, and you can create custom roles.
| Role | Description |
|---|---|
| Owner | Full administrative access |
| Admin | Administrative access without billing |
| Member | Standard user access |
| Viewer | Read-only access |
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 |
A Network is a supported blockchain where you can send transactions and hold assets.
| 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 |
Start with Cubewire Testnet for development—it's fast, free, and purpose-built for testing. Use the Cubewire Faucet to get test tokens.
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) |
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 |
Compliance settings are configured at the organization level. Contact your account manager to customize compliance checks for your use case.