Why Authority Architecture Is the Most Important Design Decision in a Crypto Fund

Authority architecture is the complete set of rules that governs who can do what with a fund's assets, systems, and operational infrastructure. It determines which individuals or processes can trade, which can move assets, which can approve withdrawals, and which can only observe. In a traditional fund, this framework is largely imposed by regulated intermediaries and established custody conventions. In a crypto fund, it must be deliberately designed. Most funds design it badly, and most of the serious operational failures in this market can be traced to that design failure rather than to external attack.

"The question we ask every manager before they launch is: if your most trusted employee decided to act against your investors' interests tomorrow, what would stop them, and how quickly would you know? Most managers have not thought through the answer. Authority architecture is the set of controls that determines whether the answer is 'nothing' or 'everything necessary.' There is no middle ground that holds under pressure." David Lloyd, Chief Executive Officer of CV5 Capital

Why This Is a Design Problem, Not a Security Problem

Authority architecture is frequently treated as a cybersecurity concern: a matter of strong passwords, two-factor authentication, and keeping private keys offline. These are necessary conditions. They are not the primary issue. The deeper problem is structural: who has the authority to take consequential actions with fund assets, under what conditions, and what checks exist on that authority. Security measures protect against external actors who should have no access at all. Authority architecture governs internal actors who have legitimate access but whose scope of that access must be precisely bounded.

The distinction matters because the operational failures that have produced the largest investor losses in digital asset funds have typically involved internal actors operating within their existing access rather than external attackers who breached the perimeter. A portfolio manager with withdrawal access to the fund's exchange accounts requires no external attack vector to misappropriate assets. A single administrator with the ability to both initiate and approve transactions has a system design problem, not a security problem. A fund where the investment manager controls the private keys to the custody wallet has granted an authority that no institutional governance framework should allow, regardless of the integrity of the individual holding it.

Designing authority architecture correctly means mapping every consequential action that can be taken with fund assets, assigning permission levels to each action, and ensuring that no single individual can complete a high-risk action without the participation and awareness of at least one other independent party. This is the four-eyes principle applied to digital asset infrastructure, and it is the governance standard that institutional allocators conducting operational due diligence expect to find.

Exchange Access: Three Tiers That Must Not Be Collapsed

Centralised exchange access is the point at which authority architecture failures most frequently occur in practice, because exchanges provide multiple capability levels through a single interface, and most managers default to granting the broadest access to everyone who needs any access at all. The correct approach is a strict three-tier permission model applied to every exchange relationship the fund maintains.

Sub-Account Architecture

Major institutional exchanges provide sub-account functionality that allows a master account to be divided into operationally distinct sub-accounts, each with its own balance, position history, and API credentials. For a fund operating across multiple strategies or multiple segregated portfolios within an SPC structure, sub-accounts are the correct tool for maintaining clean separation between portfolio-level positions, performance attribution, and counterparty exposure tracking. Each sub-account should be treated as an independent permission boundary, with its own API key set, its own withdrawal whitelist, and its own reconciliation trail for the fund administrator.

Sub-accounts do not eliminate exchange counterparty risk. They are a tool for internal operational control within a single exchange relationship. The fund's exchange counterparty risk framework, which should specify maximum balances permitted per exchange, remains applicable at the master account level. The institutional custody framework that governs the fund's primary asset safekeeping is a separate and complementary layer of protection.

Wallet Permissions: Tiered Control from Cold to Hot

The fund's on-chain wallet infrastructure must be designed around a tiered permission model that matches custody tier to the access controls appropriate for assets at that tier. The three tiers are cold storage, warm storage, and hot wallets used for operational purposes. The controls applied to each tier differ in terms of signature requirements, geographic distribution of key material, time-lock provisions, and approval workflow.

Cold Storage: Maximum Control, Minimum Accessibility

Cold storage wallets hold the majority of the fund's on-chain assets and are not connected to any network during normal operation. Private keys for cold storage wallets are generated and stored on hardware security modules (HSMs) or dedicated hardware signing devices that have never been connected to an internet-connected system. The signing process for a cold storage transaction requires physical access to the hardware device and satisfies a multi-signature threshold that is set by the custodian's key management policy.

For an institutional custodian, the standard cold storage arrangement requires a minimum of two independent signatories to authorise a transaction, with the signing devices held in geographically distributed secure facilities. No single individual has access to sufficient key material to authorise a transaction unilaterally. The investment manager participates in the authorisation workflow as an instruction initiator, but cannot complete the authorisation without the custodian's concurrent approval. This structure means that the investment manager's compromise or misconduct cannot result in unilateral extraction of cold storage assets.

Warm Storage: Operational Flexibility with Structural Control

Warm storage wallets hold assets that need to be accessible within hours rather than days. They are typically held in multi-signature arrangements where the signing keys are stored on HSMs that are network-connected but behind strict access controls and monitoring. The multi-signature threshold for warm storage is typically lower than for cold storage (two of three rather than three of five, for example) to support faster transaction processing, but the requirement for multiple independent approvals is maintained. Warm storage is used for assets that the investment manager expects to deploy within a dealing cycle, and for funding exchange sub-accounts within the fund's approved counterparty limits.

The movement of assets from cold storage to warm storage is itself a high-risk action that must be subject to the fund's full authorisation workflow. An architecture that allows the investment manager to move assets from cold to warm storage unilaterally has effectively removed the protection of cold storage. Pre-approved operational funding limits, rather than ad hoc authorisations, are the appropriate mechanism for managing the cold-to-warm transfer process.

Hot Wallets: Strictly Limited Operational Balances

Hot wallets are network-connected wallets used for immediate operational needs: gas fees for on-chain transactions, protocol interactions, and small-scale operational transfers. They should hold the minimum balance required for operational purposes, defined by a documented policy, and replenished from warm storage through the standard authorisation workflow. They must never be used as a substitute for proper custody arrangements and must never hold a material proportion of the fund's assets. Any hot wallet balance that exceeds the operational minimum represents an unnecessary concentration of easily accessible, lightly controlled assets.

API Controls: The Attack Surface Most Funds Leave Unmanaged

Application programming interface keys are the credentials through which the fund's trading systems, risk monitoring tools, administrator reporting integrations, and execution algorithms interact with exchange and custody infrastructure. They are also one of the most common vectors for operational failure in crypto fund management, not because they are inherently insecure, but because most funds do not manage them with the discipline that their risk profile demands.

Key Scoping: Minimum Necessary Permissions

Every API key must be provisioned with the minimum permissions required for its specific function. A key used by the administrator's reporting system requires read-only access and nothing more. A key used by the execution algorithm requires trade permissions and nothing more. A key used for automated position reporting requires read access to specific sub-accounts and nothing more. The common practice of provisioning a single general-purpose API key with broad permissions, shared across multiple systems or teams, eliminates the ability to trace actions to specific systems, revoke compromised credentials without disrupting unaffected functions, and maintain a clean audit trail for the fund administrator and auditor.

IP Whitelisting

Every API key should be restricted to the specific IP addresses of the systems authorised to use it. A trading algorithm's API key should only function when requests originate from the trading server's IP address. An administrator's reporting key should only function from the administrator's system IP range. IP whitelisting does not eliminate the risk of credential compromise, but it substantially reduces the consequences of that compromise: a stolen API key that can only be used from a whitelisted IP address is unusable by an external attacker who does not also have access to the whitelisted system.

Key Rotation and Lifecycle Management

API keys must be rotated on a defined schedule, typically every 90 days for trading keys and every 180 days for read-only reporting keys. The rotation schedule must be documented and tracked as a governance obligation, not left to the discretion of the individual who manages the trading systems. Unscheduled key rotation must be triggered immediately if there is any indication that a key may have been compromised: a system breach, a personnel departure, a security incident at a third-party system that held the key, or simply a period of unexpected account activity that cannot be attributed to authorised operations.

The fund must maintain a key register that records, for each active key: the system or individual to whom it is provisioned, the permission scope, the IP whitelist, the creation date, the most recent rotation date, the next scheduled rotation date, and the identity of the individual responsible for rotation. This register must be reviewed and certified by the compliance function on a periodic basis and made available to the fund administrator and auditor on request.

Segregation of Duties: The Four-Eyes Principle in Practice

Segregation of duties is the governance principle that no single individual should have end-to-end control over a high-risk process. In an institutional financial context, it is the principle that the person who initiates a payment should not be the person who approves it, and the person who approves it should not be the person who reconciles it. In a crypto fund context, the equivalent principle requires that the ability to instruct an asset movement, the authority to approve that movement, and the ability to verify that it occurred correctly are held by separate parties.

The segregation of duties framework for a crypto fund maps across four functional areas: investment authority, operational authority, custodial authority, and verification authority. The boundary between these areas must be maintained in the fund's documented procedures and in the practical reality of its systems access. A fund where the investment manager also controls withdrawal authority has collapsed two of these four areas into one. A fund where the same individual manages the key register and executes trades using those keys has collapsed two others. Either collapse creates a single point of failure that represents both an operational risk and a governance deficiency that institutional allocators will identify during due diligence.

The Authority Matrix

The authority matrix is the practical document that maps each consequential action to the parties who may initiate it, the parties who must approve it, and the parties who verify it. It is the single most useful governance document for establishing that segregation of duties has been correctly designed and for demonstrating that design to allocators, auditors, and regulators. A fund that cannot produce an authority matrix in a due diligence process cannot demonstrate that its controls have been deliberately designed rather than accidentally adequate.

The authority matrix is a living document. Every time the fund's operational arrangements change, including a change in service providers, a change in team composition, the addition of a new exchange or protocol relationship, or a change in the fund's trading instruments, the authority matrix must be reviewed and updated. A matrix that does not reflect current operational reality provides false assurance and fails as a governance instrument.

Audit Trail Requirements: Controls That Cannot Be Verified Are Controls That Do Not Exist

Every action within the authority architecture must generate an immutable, timestamped record that is accessible to the fund administrator, the auditor, and the compliance function independently of the investment manager. This requirement is not satisfied by exchange account logs that the investment manager controls or by an internal system whose records can be altered by the same party who executes the transactions.

The audit trail for an institutional crypto fund must capture, at minimum: every trade executed, with timestamp, instrument, size, price, and the API key or access credential that placed the order; every asset movement, with timestamp, amount, originating address or account, destination address or account, the approving parties, and the transaction ID on the relevant chain or exchange; every API key provisioning and revocation event; every addition to and removal from the withdrawal whitelist; and every board resolution and board minute that authorises or documents a material change to the fund's authority framework.

The administrator's independent receipt of trade and position data from the custodian, rather than from the investment manager, is the foundational control that makes the audit trail meaningful. Where the administrator's records are sourced independently from the custodian and exchange, they provide a verification layer for the investment manager's own records. Discrepancies between the two sources are detected immediately and must be resolved before the next NAV calculation. This is the operational architecture that the daily NAV framework depends on for integrity, and it is the same architecture that makes the annual audit tractable rather than a months-long reconstruction exercise.

A Practical Framework for Designing Authority Architecture from Launch

Authority architecture should be designed before the fund accepts its first subscription, not incrementally added as operational problems are discovered. The following framework provides a structured approach to that design process, sequenced from the highest-risk decisions to the supporting controls.

What Institutional Allocators Look for in an Authority Architecture Review

Operational due diligence for a crypto fund will include a review of the fund's authority architecture, whether or not the allocator describes it in those terms. The questions they ask map directly to the framework described above. Managers who have designed authority architecture correctly, documented it in an authority matrix, and configured their systems to enforce it are substantially better positioned to progress through this process than managers who are reconstructing their controls from memory in response to a questionnaire.

The specific questions that reveal the quality of a fund's authority architecture most reliably are: Can the investment manager unilaterally move assets out of custody? What is the approval process for withdrawals, and who are the independent approvers? How many API keys are active, what permissions do each carry, and when were they last rotated? Has there ever been an unauthorised access event or an attempt to exceed mandate authority, and how was it detected? These questions cannot be answered convincingly with general reassurance. They can only be answered with documentation, configuration records, and a demonstrated understanding of why each control exists.

Managers launching on the CV5 Capital digital asset fund platform benefit from an authority architecture framework that has been designed, documented, and tested as part of the platform's standard operational infrastructure. The institutional custodian relationships, the administrator's independent data feed from the custodian, the multi-signature withdrawal controls, and the governance documentation that supports the authority matrix are components of the platform that each new fund operates within from its first dealing date. The custody model and the NAV integrity framework that depend on this architecture are also addressed in detail across the CV5 Capital Insights library.

Key Takeaways

• Authority architecture is the complete set of rules governing who can take consequential actions with fund assets, under what conditions, and subject to which checks. It is a governance design problem, not a cybersecurity problem, and the most serious operational failures in digital asset fund management originate in its absence rather than in external attack.
• Exchange access must follow a strict three-tier model: read-only for administrators and monitoring systems, trade-only for the investment manager and execution algorithms, and withdrawal authority requiring independent multi-party approval. Combining withdrawal authority with trade authority in a single access credential is the single most common control deficiency in crypto fund operations.
• On-chain wallet infrastructure must be tiered from cold to hot storage, with each tier's access controls calibrated to the risk of the assets held there. The movement of assets between tiers is itself a high-risk action requiring multi-party authorisation. No unilateral movement by the investment manager should be possible at any custody tier.
• API keys must be scoped to minimum necessary permissions, restricted by IP whitelist, rotated on a defined schedule, and managed through a key register maintained by the compliance function independently of the trading team. The individual who manages API keys must not be the individual who uses them for trading.
• Segregation of duties requires that investment authority, operational authority, custodial authority, and verification authority are held by separate parties. The authority matrix is the document that maps these assignments explicitly and that must be configured in systems, not merely stated in policy.
• Authority architecture must be designed before launch, tested before the first subscription, and reviewed on a minimum six-month cycle and upon any material operational change. An architecture that has not been maintained since launch provides governance assurance that does not reflect the fund's actual operational risk profile.