Processes

Multi-signature

Typically, when a transaction is initiated by the first signer, it is automatically signed and stored as a partially signed transaction in IPFS. Other signers within your organisation or from external organisations that also use CoKeeps Wallet can then retrieve and sign this transaction until the required threshold is met.

Any deviation from the policy rules configured for the multi-signature account results in a transaction error. Policy enforcement is mandatory for custodial accounts and strongly recommended for sensitive assets. Policies can define who is allowed to initiate transactions, set maximum transfer amounts, and restrict destinations beyond the organisation's global whitelists.

Once a multi-signature account satisfies its threshold requirement, the final signer automatically relays the transaction to the blockchain network and pays the associated transaction fees. For Solana, however, each additional signature is itself an on-chain action and requires SOL. To avoid the need for every member to hold SOL, each multi-signature account is assigned a dedicated "gas station" address that covers these approval costs.

If some owners of a multi-signature account do not use CoKeeps Wallet, they can still participate by signing the transaction independently with their own wallet at the final stage and relaying it directly to the network.

Batch transfers

All EVM-based tokens (ERC-20) can leverage our Batch Sender smart contract, which enables multiple token transfers to be executed within a single transaction. This approach can significantly reduce overall transaction fees, often by as much as 70% compared to performing individual transfers.

Batch transfers can be initiated from a Personal account for maximum cost efficiency. Alternatively, using a Shared (multi-signature) account is well-suited for activities such as large-scale airdrops, where involving multiple stakeholders in the approval process is desirable to prevent any single individual from having full control over the operation. This governance benefit comes with a higher transaction cost compared to executing the batch from a Personal account.

Staking

CoKeeps currently offers Direct Staking for supported networks directly from the CoKeeps Wallet. In this model, CoKeeps facilitates the staking procedure with our trusted staking providers (node validators), but operational control and responsibility remain entirely with you.

Because staking operations are sensitive and misconfiguration can lead to loss of assets, you must first prepare the appropriate dedicated accounts before initiating staking. The feature is available via the Cold Wallet, but you are required to contact CoKeeps personnel before proceeding so we can help verify that your setup, accounts, and flows are correctly configured.

At present, Direct Staking is available for:

• Ethereum: Minimum stake: 32 ETH (network-native asset). Rewards are automatically compounded under the default 0x02 validator configuration.
• Solana: Minimum stake: 1 SOL (network-native asset).

Coming Soon

• Pool Staking: Allows you to stake with smaller amounts than the native minimums. In this model, CoKeeps controls the staking operations while you participate via pooled positions.
• Staking with Stablecoins: Staking strategies utilising supported tokenised stablecoins, providing additional yield options beyond native assets.

Recovery

There are two types of recovery procedures, each serving a distinct purpose and operating independently of one another.

Wallet Recovery

Wallet recovery relates to the key generation and access for Managed Self-Custody accounts.

When a signer first starts using CoKeeps Wallet, the recovery secret is split into three shards:

• One shard is stored securely (encrypted) by the CoKeeps system.
• One shard is provided to the signer, who is responsible for storing it securely.
• One shard is provided for your organisation, to be entrusted to a responsible individual (for example, an infosec or security owner).

A minimum of two shards is required to reconstruct the recovery information.

If a signer forgets their credentials, CoKeeps Wallet can guide the recovery process using two of the three shards. If a signer becomes unavailable and your organisation needs to recover the balances associated with that signer's single-signature accounts, the shard held by your organisation, combined with the shard stored by CoKeeps, can be used for recovery.

CoKeeps cannot perform recovery on its own using only the system shard. The shard stored by CoKeeps is solely intended to assist in recovery when a signer is missing and your organisation approves the procedure. If there are no balances in any accounts created under that signer's single-signature profile, wallet recovery is not necessary.

Wallet recovery is not intended to "reassign" a signer identity to a new person. If you need to replace a signer, we strongly recommend creating a new signer and updating multi-signature configurations and policies accordingly.

Multi-signature Recovery

Multi-signature recovery focuses on multi-signature accounts and is used when one or more existing signers are missing, compromised, or no longer serving the organisation.

In this procedure, the entire asset balance of the affected multi-signature account is transferred to a new multi-signature account with an updated set of signers. The original account is effectively retired for operational use.

We recommend that the newly created multi-signature account be of equal or higher security level than the original. For example:

• A 2-of-3 multi-signature account should recover to another 2-of-3 or a 3-of-5 account.
• Downgrading from a 3-of-5 to a 2-of-3 multi-signature account is not advisable, as it may weaken your security posture and governance model.

Hot Wallet

Sweep

The sweep procedure transfers all balances from Deposit addresses (each uniquely generated for your end users via the Hot Wallet) into a designated account such as a Holding, omnibus, or Withdrawal account. The sweep action is performed using the CoKeeps SDK (CKSDK) by an admin user who has been granted the appropriate scope and permissions.

Re-balance

Re-balancing is a procedure that keeps the balance ratio between Holding (more secure) and Withdrawal accounts aligned with the target ratio defined at the time you execute the re-balance action via CKSDK.

For example, if you define a 70% Holding / 30% Withdrawal ratio, the re-balance procedure will transfer funds between these accounts as needed to restore that ratio.

Re-balancing is typically performed on a periodic basis (for example, weekly) and should also be triggered when the Withdrawal account balance becomes low. The ratio should be tuned based on your platform's withdrawal activity - for instance, sustained high withdrawal volume may warrant increasing the allocation toward the Withdrawal account.

Re-balancing is not automated by default and must be initiated and reviewed manually. However, you can program this operation on your side to be triggered automatically on a scheduled basis via the CKSDK.

Withdrawal

By default, when your user submits a destination address in your own platform, your backend provides that destination to CoKeeps Hot Wallet. If the destination address is correctly supplied and passes basic checks, the withdrawal can be executed immediately. However, you may still choose to implement additional internal authorisation, screening, or review steps in your own backend before returning the final destination to CoKeeps.

You can implement and manage these procedures within your own administration interface by integrating CKSDK directly, or you can use CoKeeps' optional withdrawal approval flow, which can be enabled on request.

Once a withdrawal to a specific destination address has been approved, subsequent withdrawals to the same address can be processed more quickly or even instantly, depending on how your backend is integrated and how it responds to CoKeeps Hot Wallet. The detailed flow is explained in the Hot Wallet backend section.

Travel Rule

By default, all withdrawal procedures require destination addresses to be approved by your organisation, as described above. The information supplied by your users when specifying a destination may need to comply with the Financial Action Task Force (FATF) Recommendation 16, commonly known as the Travel Rule (for example, originator and beneficiary information for certain transfers). CKSDK can help you collect, attach, and manage this information as part of your withdrawal flow.

Dynamic Transaction Pool

The Dynamic Transaction Pool is a staging area for all transactions initiated via CoKeeps Hot Wallet that involve omnibus Holding accounts. Instead of being sent to the blockchain immediately, these transactions are first placed into the pool, where they can:

• Serve as a record of pending and historical omnibus transactions,
• Undergo multi-approval (maker–checker) workflows in line with your policies, and
• Be screened for compliance, risk, and business rules before final execution.

Once a transaction has passed the required checks and approvals, it can then be released from the pool and broadcast on-chain, providing an additional layer of governance and control over omnibus activity.

Dynamic Ledger

The Dynamic Ledger is an optional off-chain ledger that you can use alongside your existing internal ledger for reconciliation and integrity checking, or as your primary ledger if you do not already have one. It is particularly useful for omnibus-style structures, where a single on-chain account represents many virtual user balances. The ledger is designed with banking-grade numeric precision to accurately handle decimal places and large volumes of transactions.

Monitoring and tools

CoKeeps provides a comprehensive toolset accessible via REST APIs and webhooks, enabling you to monitor transaction statuses, track address history, and integrate event-driven workflows. Additional utilities include address validation, balance lookups, average fee estimation, and other helper functions to support operational monitoring and automation.