Glossary

This glossary summarises key concepts, roles, account types, and features used throughout the CoKeeps documentation. Use it as a quick reference while integrating CoKeeps Wallet and Hot Wallet.

1. Core Concepts

CoKeeps Wallet

The overall platform for managing digital assets in an organisational context. It includes Client Administration, Cold Wallet, Hot Wallet, access controls, policies, and supporting services.

Cold Wallet

A security-focused component used by designated signers to create and approve transactions, manage single- and multi-signature accounts, and perform key-related operations. Keys are generated on-device and never stored by CoKeeps.

Hot Wallet

A modular, API-driven component that enables automated and high-volume operations (deposits, withdrawals, omnibus structures, smart contract interactions, etc.) for your platform. It is integrated via CoKeeps SDK (CKSDK) and backed by your own back-end service.

CKSDK (CoKeeps SDK)

The JavaScript/Node.js SDK that handles cryptographic operations, secure communication, and interaction with the CoKeeps Hot Wallet. CKSDK manages per-user keypairs, message signing, encryption, and higher-level actions such as transfers, contract interactions, and omnibus withdrawals.

Single Tenant Deployment

Each customer runs in an isolated environment (infrastructure, networks, and database). No data or execution is shared across tenants.

2. Components

Client Administration

The web interface for configuring CoKeeps Wallet behaviour, managing users, roles, networks, policies, smart contracts, and Hot Wallet settings.

CoKeeps Cold Wallet Application

The application (typically desktop or dedicated device) used by signers to create and sign transactions, manage multi-signature accounts, and execute sensitive operations.

CoKeeps Hot Wallet Service

The back-end service that receives CKSDK requests, enforces policies, coordinates with your back-end via the 4 integration endpoints, and executes on-chain actions where appropriate.

Your Back-End Service

Your own server-side application that CoKeeps Hot Wallet talks to through four REST endpoints (user_verify, machine_verify, read, and update). It provides identity, authorisation, limits, destinations, and receives notifications.

Dynamic Ledger

An optional off-chain ledger maintained by CoKeeps for omnibus-style structures. It tracks per-user balances, total balances, and pending amounts for assets held in an omnibus account.

Dynamic Transaction Pool

A queue of pending omnibus withdrawal requests and related multi-signature transaction data. Used to drive approval, review, and relay workflows for omnibus withdrawals.

Gas Station

A mechanism and associated account used to automatically fund addresses with enough base asset (native coin) to pay transaction fees. Configured via CoKeeps Cold Wallet and used by Hot Wallet operations.

3. Roles

Authoriser

An organisational role responsible for configuration and governance: managing users, roles, policies, contacts, connected smart contracts, and Hot Wallet settings. Authorisers can be scoped (e.g. one for users/roles, one for smart contracts, one for policies).

Payer

An optional role restricted to subscription and payment management. Payers do not have operational or transaction capabilities.

Signer

A human or machine acting as a signer for accounts. Signers create and approve transactions, sign messages, and participate in multi-signature operations.

Hot Wallet User (user role)

An end user of your platform who uses Hot Wallet features (e.g. creating deposit addresses, submitting withdrawals). Identified by a UUID in your system and authenticated via CKSDK.

Hot Wallet Admin (admin role)

An elevated Hot Wallet user who can perform everything a user can, plus administrative actions such as sweeping, rebalancing, approving destinations, approving reviews, and managing omnibus workflows. Admins cannot approve their own actions.

Machine

A non-human actor (e.g. service or daemon) that performs automated tasks via Hot Wallet, typically represented as a machine signer. Machines are verified via machine_verify on your back-end.

4. Account Types & Structures

Personal Account (Single Signature)

An account controlled by a single signer in the Cold Wallet. Referred to as “Personal” in the platform UI. Suitable for individual signers or operational roles with lower risk requirements.

Shared Account (Multi-Signature)

An account that requires multiple signatures to approve a transaction. Referred to as “Shared” in the Cold Wallet. Used for governance, high-value assets, and regulated flows.

Custodial Account

A multi-signature account that includes at least one CoKeeps signer as a member. Used when CoKeeps acts as a regulated custodian or participates in recovery/governance.

Managed Self Custody

Single or multi-signature accounts created in CoKeeps Wallet where your own organisation controls the members and keys. CoKeeps may be involved for tooling but not necessarily as a signer.

Partial Custody

Multi-signature accounts where CoKeeps signers are in the minority. Typically used when CoKeeps is only needed for recovery or oversight, not day-to-day transaction approvals.

Full Custody

Multi-signature accounts where CoKeeps signers are the majority, usually for regulated custody arrangements where CoKeeps participates actively in transaction approvals and policy enforcement.

Deposit Account

A dedicated address used to receive inbound transfers for a specific user (per chain). Intended as a temporary entry point so deposits can be identified and later swept to Holding or Withdrawal accounts.

Holding Account

A multi-signature account used as an omnibus storage location for aggregated deposits. Often controlled by human signers, with partial balances moved to Withdrawal accounts to serve end-user withdrawals.

Withdrawal Account

An account funded from a Holding account to service outbound transfers to end-user destinations. Designed to offer fast withdrawal execution while leaving most assets in more tightly controlled holdings.

Signer Wallet

A single-signature account derived from a label and unique per user. Used for:

• On-chain actions directly controlled by users (like a Metamask-style wallet).
• Participation as a member in multi-signature accounts.
• Lightweight omnibus or operational addresses.

Special Accounts

Accounts created via Hot Wallet modules, often using MPC-style key management rather than on-device generation. Typically not accessible directly via Cold Wallet and managed via CKSDK.

5. Hot Wallet & CKSDK Concepts

CKSDK (Frontend)

The browser-side CKSDK used in web applications. Generates and stores per-user cryptographic keypairs on the user's device, signs and encrypts requests, and communicates directly with CoKeeps Hot Wallet over HTTPS.

CKSDK (Bridge / Backend)

A pattern where:

• Frontend uses a lightweight bridge to wrap user credentials and send a sealed value.
• Backend uses Node.js CKSDK to perform Hot Wallet operations on behalf of the user, using the sealed data. Improves security and accountability compared to pure backend-only usage.

CKSDK (Backend-Only)

A pattern where CKSDK runs exclusively on your backend, and your system supplies deterministic username/password equivalents. Simplest to implement but with lower accountability (similar to per-user API keys) and higher responsibility on your internal safeguards.

Hashed Username

A SHA-256 hash of the user's identifier (e.g. username/email). Used by CoKeeps Hot Wallet during user_verify to identify users without exposing raw identifiers.

Hashed Password

A SHA-256 hash derived from the user's credential value. Used only to derive keys for Hot Wallet authentication and must remain stable even after password resets (you should not delete or overwrite the original hash used for Hot Wallet mapping).

x Value (Challenge)

A random value sent by CoKeeps Hot Wallet to your back-end in user_verify and machine_verify. Your system combines it with a salt to derive a deterministic key that proves continuity and integrity of the authentication flow.

Role (signer / admin)

The field returned by your read endpoint that tells CoKeeps whether the user is a regular Hot Wallet user (signer) or an elevated user (admin). Determines which CKSDK features are available.

6. Data & Security

UUID (User ID)

A Universally Unique Identifier used to represent users in CoKeeps systems. CoKeeps requires a UUID from your back-end instead of PII (e.g. names or emails).

SBDV (Signature Based Data Verification)

A mechanism where CKSDK signs request data, and signatures are stored alongside records. When the system reads the record, it verifies the signature to ensure:

• Integrity (data has not been tampered with).
• Accountability (which user signed it).

AES Encryption

Symmetric encryption used for all payloads between CoKeeps Hot Wallet and your back-end service. Both sides share a secret key for encryption and decryption.

Shared Secret

The symmetric key used by CoKeeps Hot Wallet and your back-end for AES payload encryption. Generated and provided by CoKeeps during integration, then stored securely on your side (e.g. environment variables, secret manager).

Salt

A secret value used by your back-end to derive the key in user_verify / machine_verify (e.g. key = SHA256(salt + x)). CoKeeps never sees the salt. It must remain deterministic and stable.

Shamir Secret Sharing

An optional strategy to split the secret or salt into multiple shards. A subset of shards is required to reconstruct the original value, reducing single points of failure.

SBDV Flag

A Boolean marker on stored records (e.g. destinations, Travel Rules, pool entries) indicating that the data has passed SBDV validation and has not been tampered with.

No PII Policy

CoKeeps Hot Wallet does not require or store Personally Identifiable Information. Only UUIDs and pseudonymous identifiers are used for user references.

SOC 1, SOC 2, ISO 27001

Independent certifications and audits demonstrating that CoKeeps' security controls, processes, and data management practices meet recognised industry standards.

7. Governance, Policy & Compliance

Multi-Signature Policy

A set of rules attached to a multi-signature account that define:

• Who can initiate transactions.
• Limits per transaction / per period.
• Allowed destination patterns or whitelisted addresses. Policies are mandatory for custodial accounts and recommended for sensitive assets.

Contact

A whitelisted address or public key stored in CoKeeps Wallet. Can be used as:

• A destination (eligible to receive outgoing transfers).
• A signer (eligible to participate in multi-signature accounts).

Destination

A specific address provided by a user for withdrawals. Usually paired with Travel Rule information and subject to administrative approval.

Travel Rule

The regulatory requirement (FATF Recommendation 16) that certain sender/receiver information accompany transfers. In CoKeeps, Travel Rule entries store the associated KYC-like metadata for destinations.

Pending Review

A queued transfer request that requires admin approval before execution. Typically used for:

• Signer Wallet transfers with moderation.
• Higher-risk or higher-value actions configured to require a second approver.

8. Operations & Flows

Sweep (Deposits)

The process of moving balances from many deposit addresses into a central account (e.g. Holding or Withdrawal). Triggered via CKSDK management actions.

Sweep (Withdrawal)

The process of draining a Withdrawal account back to a Holding account, typically to consolidate funds or rotate liquidity.

Sweep (Gas Station)

The process of draining a Gas Station account's base asset into a Holding account once it is no longer needed or needs to be rotated.

Sweep Signer Wallet Base

The process of reclaiming leftover base asset (for transaction fees) from Signer Wallets that no longer hold tokens, consolidating gas funds.

Re-balance

An operation that adjusts the balance distribution between Holding and Withdrawal accounts according to a ratio or fixed amount (e.g. from 30:70 to 70:30), while respecting available balances and fees.

Omnibus Account

An on-chain account that holds assets on behalf of many end users, with their individual balances tracked off-chain (e.g. Dynamic Ledger). Often configured as a multi-signature account with policy rules.

Omnibus Withdrawal

A withdrawal flow where:

• The user requests a withdrawal (using CKSDK).
• The request is recorded in Dynamic Transaction Pool.
• Admins review and approve.
• A multi-signature transaction is built and relayed from the omnibus account to the user's destination.

Batch Transfers

An optimised process (typically via smart contracts on EVM chains) that sends many token transfers in a single transaction. Used for cost-effective airdrops or bulk payouts.

Direct Staking

Staking operations executed from CoKeeps Wallet directly (e.g. Ethereum, Solana) while you maintain control of the accounts and parameters. CoKeeps facilitates the flow but does not control the staked assets.

9. MasChain (Optional / Advanced)

Note: This section is relevant only if you are integrating MasChain with CoKeeps KMS.

MasChain

A blockchain environment that integrates with CoKeeps KMS for smart contract deployment, governance, and multi-signature upgradeability.

MasChain Single-Signature Wallet

A per-user wallet on MasChain or MasChain testnet generated via CKSDK (MasChain scope). It behaves like a typical EVM wallet for direct contract interactions.

MasChain Multi-Signature Wallet

A multi-signature contract on MasChain where:

• Owners are single-signature wallets.
• Threshold defines how many signatures are required to authorise a transaction.
• Used for governance over contracts, token minting, upgrades, and other sensitive operations.

Project Slug / Version Slug

Identifiers corresponding to a smart-contract project and version uploaded to the MasChain platform. Used by CKSDK MasChain methods to build and encode contract calls.

If a term you're looking for is not listed here, check the Integration Strategy, Hot Wallet, Cold Wallet, or CKSDK sections for deeper context and examples.