A Risk Rating Framework for DeFi and Crypto Investors

Introduction 

"Risk comes from not knowing what you're doing." – Warren Buffett 

In capital markets, risk is not an afterthought for sophisticated investors. It is the essential counterpart to reward, the inextricable yin to its yang, the other side of the coin without which value cannot be meaningfully assessed.  

Bond traders have ratings agencies. Consumer lenders rely on FICO scores. Insurance underwriters look at actuarial tables.  Banks turn to Basel risk weightings to gauge how much capital they must hold against various assets. But in cryptocurrency and decentralized finance (DeFi), there is no customizable lingua franca for benchmarking protocol risk on an apples-to-apples basis.  

This paper is the first in a series focused on establishing a transparent DeFi ratings framework, free from the moral hazard traditional ratings agencies may face at times, with their opaque models and misaligned incentives. 

Executive Summary 

This paper seeks to formalize a comprehensive operational venue risk management methodology tailored specifically for evaluating and interacting with DeFi protocols. The primary objective is to translate the novel and often opaque risks inherent to operating in DeFi into a structured framework that meshes with traditional financial and operational risk paradigms. The framework also sets a minimum threshold of viability for protocol engagement, and a tiering approach for those protocols that pass the minimum threshold. 

To operationalize the methodology, this paper introduces the SeC FiT PrO framework. SeC FiT Pro outlines a domain-weighted scoring matrix that evaluates protocols across six risk domains: Security, Compliance, Finance, Technology, Protocol, and Operations. Each domain is assigned a weight based on its relative significance, and protocols are evaluated to generate a composite risk score. This score determines whether it is prudent to interact with a given protocol, and if so, what level of exposure is appropriate depending on an investor’s risk appetite, supporting infrastructure, portfolio composition, and the protocol’s score.  

These factors and their weights are based on the experience of Galaxy’s trading, risk, and operations teams in managing more than $1 billion in onchain assets. But this framework and its component weights should be considered a mutable set of guidelines that can, and should, be tailored to any investor’s risk profile and capabilities. 

DeFi Operational Risk Assessment 

The core of the framework is a domain-based risk scoring methodology that evaluates DeFi protocols based on a set of factors under six primary domains. Each domain encompasses specific sub-risk factors relevant to institutional engagement with DeFi protocols. The methodology relies on both quantitative scores and qualitative judgments to deliver a standardized risk assessment. At the heart of this approach is a scoring table where each risk domain is assigned a weight. Individual risk factors within those domains are also assigned weights and a composite weighted score is calculated. 

The result is a final operational risk score that indicates the protocol’s overall risk level and compliance with the minimum viability criteria.  A protocol’s aggregate score should be viewed not in isolation but relative to other protocols. The baseline level of risk is not being evaluated in this analysis framework, merely the relative level of risk between DeFi protocols. A forthcoming paper on market risk management of a hybrid TradFi-DeFi, or purely DeFi portfolio, expounds on the ideas of risk-adjusted exposures to DeFi protocols through the lens of a credit manager. 

Risk Domains 

1. Security Risk Assessment – Weight (20%) 

Security considerations are paramount and begin with a holistic review of the protocol’s infrastructure security posture. This includes both self-attested controls and third-party verification through penetration testing and audits. Protocol smart contract audits are reviewed for their recency, scope, and the credibility of the auditing firm. Particular weight is given to whether the protocol development team has addressed known vulnerabilities. The prospective investor’s security controls are also reviewed; key management controls are closely examined with respect to generation, usage, backup, and revocation processes. Investor operational security measures are evaluated in terms of implemented policies, access controls, and system monitoring. The investor’s ability to generate and maintain comprehensive audit logs that can be consumed by compliance and operations teams is another critical consideration.  

Components 

• Onchain infrastructure security review and testing 

  • Investor security team review of infrastructure and associated security controls of the protocol.  If security reviewer is external, that third party must provide evidence that the protocol team has applied controls. 

  • Weight: 25% 

  • Scoring guideline: 

    • 🟢 5 - Meets all enhanced industry-standard controls for associated cloud and blockchain infrastructure and documents and enforces security at every step.  Has conducted technical penetration testing <1 year. 

    • 🟡 3 - Meets all enhanced industry standard controls for associated cloud and blockchain infrastructure.  Has conducted technical penetration testing < 1 year. 

    • 🔴 1 - Meets basic levels of cloud and blockchain security.  Design has been reviewed by a third party. 

• Key management controls 

  • Has the investor security team reviewed key generation, usage, storage, backup, and grant and revoke policies? Has the investor security team found them to be within Cryptocurrency Security Standard (CCSS) standards? 

  • Weight: 25% 

  • Scoring guideline: 

    • 🟢 5 - Meets relevant CCSS III standards for key material management 

    • 🟡 3 - Meets relevant CCSS II standards for key material management 

    • 🔴 1 - Meets relevant CCSS I standards for key material management 

• Smart contract review 

  • Has there been a credible smart contract audit conducted within the past year by a reputable firm? 

  • Smart contract risk is a much larger concept that will be expounded upon in a later paper. 

  • Weight: 25% 

  • Scoring guideline: 

    • 🟢 5 - Current smart contract version has been reviewed in the last six months by multiple third parties and all issues have been remediated. 

    • 🟡 3 - Current smart contract version has been reviewed in the last year by a reputable firm and all high and critical findings have been remediated. 

    • 🔴 1 - Smart contract has been reviewed by a reputable firm but the audit is out of date or high/critical findings remain. 

• Operational security controls 

  • Has the investor’s security team reviewed its own operational security controls, policies, and procedures for interacting with the protocol? 

  • Weight: 15% 

  • Scoring guideline: 

    • 🟢 5 - Formalized policies/procedures and implemented controls for systems security operation. 

    • 🟡 3 - Informal policies/procedures and implemented controls for systems security operation. 

    • 🔴 1 - Virtually no policies for security operation. 

• Audit logging 

  • Is the investor able to provide audit logging to its security and operations teams? 

  • Weight: 10% 

  • Scoring guideline: 

    • 🟢 5 - Provides robust logging of all activity. 

    • 🟡 3 - Provides many useful security logs. 

    • 🔴 1 - Provides few useful security logs. 

2. Compliance Risk Assessment – Weight (15%) 

The compliance domain examines how well a protocol aligns with regulatory expectations and an investor’s unique compliance requirements. This begins with determining whether the protocol is compatible with the investor’s compliance monitoring tools, which are essential for real-time tracking of smart contract exposures. The clarity around legal entity assignment (e.g., will the investor’s London-based or New York-based entity be interacting with the protocol?) is also evaluated. The protocol’s jurisdictional controls, such as geo-blocking to prevent access from restricted areas, are assessed under onboarding requirements. Additionally, the availability of a regulatory sandbox or testnet environment is considered, providing a controlled setting for compliance and operational testing before full deployment.  

Components

• Compliance tool compatibility 

  • Are the investor’s compliance tools compatible with required blockchain and able to monitor all smart contracts to be interacted with? 

  • Weight: 80% 

  • Scoring guideline: 

    • 🟢 1 - All relevant smart contracts can be monitored using the compliance tool (compatible with the protocol’s blockchain). 

    • 🔴 0 - Smart contracts cannot be monitored with the compliance tool. 

• Legal entity identification 

  • Does the investor know which of its legal entities will interact with the protocol? Does the investor know which legal entity the protocol operates under (if applicable)? 

  • Weight: 10% 

  • Scoring guideline: 

    • 🟢 1 – Investor has determined which legal entity activity will be managed from. 

    • 🔴 0 - Investor has not established which legal entity activity will be managed from. 

• Onboarding 

  • Can the protocol only be operated from specific jurisdictions? Is geo-blocking enabled to prohibit users based on geographical location? 

  • Weight: 5% 

  • Scoring guideline: 

    • 🟢 1 - Restrictions are in place to clearly identify which jurisdictions the protocol can be operated from. 

    • 🔴 0 - Restrictions are not in place to prevent users in banned jurisdictions from interacting with the protocol. 

• Regulatory sandbox 

  • Is a regulatory sandbox available for the investor to test the protocol? 

  • Weight: 5% 

  • Scoring guideline: 

    • 🟢 1 - Sandbox/testnet is available for use before going live on the applicable network. 

    • 🔴 0 - No sandbox/testnet is available for use before going live on the network. 

• Potential thoughts and modifications:  

  • What is the expected weekly effort (measured in hours) by the investor’s operations and tech teams to support the protocol?  

3. Financial Risk Assessment – Weight (15%) 

The financial domain evaluates whether protocols provide adequate data for transaction-level reporting and profit and loss (PnL) accounting, or if the metrics must be collected in-house and whether the investor can adequately track those metrics. This includes assessing the availability and granularity of onchain data to support balance sheet and financial statement reconciliation. Protocols should demonstrate transparent economic structures that allow for reliable calculation of realized and unrealized PnL, particularly in cases involving yield-bearing tokens, vesting schedules, and complex reward mechanics. 

Additionally, the maturity of the supporting technology infrastructure is assessed, especially in terms of compatibility with the investing firm’s infrastructure. The novelty of the asset class represented by the protocol is also considered; novelty introduces operational complexity, regulatory uncertainty, and technological risk. Finally, the framework incorporates an evaluation of the protocol’s status under the U.S. Investment Company Act of 1940 (the “40 Act”) to determine whether it qualifies as a “good” or “bad” protocol from a regulatory compliance perspective.  

Components 

• Transaction history 

  • Are transactions easily reportable by the investor? Is the onchain data structure clearly outlined by the protocol? Is the onchain data easy for the investor's team to extract?  

  • Weight: 35% 

  • Scoring guidelines:  

    • 🟢 5 - Investor can easily access token pricing details, public wallet addresses, transaction approval history. 

    • 🟡 3 - Investor can at least get historical reports (full activity log), beginning balances, ending balances, fees, full conversion/minting history. 

    • 🔴 1 - Meets only basic levels of transaction recording details such as buys, sells, claims, bonding, unbonding, transaction hash, positions. 

• Economics (PnL) 

  • Is the PnL easily reportable by the investor’s team?  Is the onchain data structure clearly outlined by the protocol? Are rewards and vesting schedules readily available from the protocol? Is the onchain data easily extractable by the investor? 

  • Weight: 15% 

  • Scoring guidelines:  

    • 🟢 5 - Reporting available that monitors vesting schedules, rewards, restricted and unrestricted tokens. 

    • 🟡 3 - Realized/unrealized PNL provided by the protocol with pricing. 

    • 🔴 1 - No reporting available for tracking vesting schedules, rewards, etc. (must manually track through block explorers and Excel / order management system). 

• Technology 

  • Has the investor completed a maturity assessment of its internal technology that supports transaction history and PNL? Assessment is inclusive of investor ability to assess and integrate the technology into its own tech stack. 

  • Weight: 25% 

  • Scoring guidelines: 

    • 🟢 5 - Full set of API documentation, automatic vesting schedules, unlock notifications, claims notifications, reward notifications, integration with investor’s tech stack, and on-demand reporting are all available. 

    • 🟡 3 - Daily reporting available (no interaction with third party or manual block explorer search required). 

    • 🔴 1 - Manual in nature; no real integration with internal or admin systems. 

• New asset category 

  • Is the underlying asset/protocol/product a new concept to the investor?  

  • Weight: 15% 

  • Scoring guidelines: 

    • 🟢 1 - Similar assets exist, and process/controls are similar. 

    • 🔴 0 - No existing processes/controls and not like other asset classes. 

• 1940 Act Impact 

  • Are the assets held /custodied/managed by the protocol exempt from 40 act?  

  • Weight: 10% 

  • Scoring guidelines: 

    • 🟢 1 - The underlying assets acquired from the protocol are considered “good” assets and exempt under the 40 Act. 

    • 🔴 0 - The assets are considered “bad” assets and not exempt under the 40 Act.

4. Technology Risk Assessment – Weight (15%) 

Technology risk is assessed by examining a protocol’s infrastructure, integration requirements, and operational safeguards. Wallet and key infrastructure are reviewed to determine whether they are custodial or non-custodial, and whether they are supported by the investor’s custody tools.  The level of development required to integrate and interact with a protocol is another critical factor, encompassing internal development requirements, database changes, and cloud architecture configurations. The investor’s ability to enforce segregation of duties (SoD) and multi-factor authentication (MFA) in key operational processes, as well as an assessment of the weekly support effort required from the investor’s technical teams, are considered.   

Components 

• Protocol availability requirements and slashing penalties 

  • Can the investor’s tech team achieve availability requirements of the protocol to avoid slashing penalties (for example, if it runs a proof-of-stake validator that goes offline)? Is the investor able to model the impact of slashing penalties (if applicable)? 

  • Weight: 30% 

  • Scoring guideline: 

    • 🟢 5 - Acceptable penalties and high confidence in achieving availability requirements OR no requirements for availability or slashing penalties. 

    • 🟡 3 - Punitive penalties, but high level of confidence of achieving availability requirements OR appropriate penalties and low level of confidence of achieving availability requirements. 

    • 🔴 1 - Very punitive penalties or low level of confidence that investor can achieve required availability. 

• Wallet/key infrastructure 

  • Is the wallet/key infrastructure required by the protocol supported by existing investor tools? How complicated would it be to integrate the infrastructure with the investor’s existing tech stack? Is the protocol infrastructure custodial or non-custodial? 

  • Weight: 20% 

  • Scoring guideline: 

    • 🟢 5 - Wallet/key infrastructure supported by existing tools. 

    • 🟡 3 - Standard wallet/key architecture not supported by existing tools. 

    • 🔴 1 - Complex wallet/key architecture requirements. 

• Development 

  • What is the relative level of development required by the investor to interact with the protocol? Is a broad level of new IT assets required for the investor to participate? 

  • Weight: 20% 

  • Scoring guideline: 

    • 🟢 5 - Minimal technology development requirements. 

    • 🟡 3 - Moderate requirements to stand up/develop IT assets (software development, database modification, new AWS or hardware hosts). 

    • 🔴 1 - Significant requirements to stand up/develop IT assets (software development, database modification, new AWS or hardware hosts).

• Segregation of duties 

  • Is the investor able to enforce segregation of duties for critical activities (such as separating trading from withdrawals)? 

  • Weight: 20% 

  • Scoring guideline: 

    • 🟢 5 - Segregation of duties enforceable for all critical functionality (access changes, critical security setting changes, address whitelisting, coin movements). 

    • 🟡 3 - Segregation of duties enforceable for at least coin movements. 

    • 🔴 1 - Segregation of Duties not enforceable for any activities. 

• Multi-factor authentication  

  • Can the investor able enforce multi-factor authentication? 

  • Weight: 10% 

  • Scoring guideline: 

    • 🟢 1 - Multi-factor Authentication available. 

    • 🔴 0 - Multi-factor Authentication not available. 

5. Protocol Risk Assessment – Weight (20%) 

This domain focuses on the unique features of the protocol itself. The presence of a whitepaper and detailed technical documentation, including software architecture and integration diagrams, is the starting point for assessment. Protocol governance is evaluated through its treasury structure, DAO governance mechanisms, and transparency around fund custody and control. Security history is reviewed through the lens of past incidents, losses, and recovery outcomes. Financial engineering elements, such as leverage offerings, insurance, and bug bounties, are assessed to understand risk amplification and mitigation strategies. Open-source transparency, upgradeability, and reliance on external protocols are key structural risk factors. Other considerations include the founding team’s transparency, venture capital involvement, mainnet age, and the use of oracles. These are individually scored within a protocol-specific matrix to inform the overall engagement decision. 

Components

• Whitepaper and software architecture 

  • Is a whitepaper publicly available from the protocol? Does the whitepaper have ample details regarding the protocol’s architecture? 

  • Weight: 20% 

  • Scoring guideline: 

    • 🟢 5 - A whitepaper is available. Additionally, documentation is available to identify the protocol’s software architecture and contract integrations through diagrams, flowcharts, or written procedures. 

    • 🟡 3 - A whitepaper or overview of the protocol is available. 

    • 🔴 1 - No whitepaper or protocol overview is available. 

• Treasury 

  • Does the protocol have a treasury reserve? What is the composition of the protocol treasury reserve? How is the treasury governed? 

  • Weight: 15% 

  • Scoring guideline: 

    • 🟢 5 - Documentation is available from the protocol to confirm if it maintains a treasury or DAO. Information is disclosed for the DAO’s smart contracts, governance structure, voting proposals, and delegation of votes. Total assets maintained in the DAO and the distribution of tokens among founders, team members, investors, and community participants are disclosed. Additionally, disclosures are available for the maintenance of private keys or admin credentials that the protocol team could use to affect the DAO. 

    • 🟡 3 - Documentation is available from the protocol to confirm if it maintains a treasury or DAO. However, protocol disclosures regarding the maintenance of funds, governance structure, voting structure, and maintenance of private key/admin credentials are limited.  

    • 🔴 1 - Documentation is unavailable and the investor cannot confirm if the protocol maintains a treasury or DAO. 

• Security incidents 

  • How many protocol security incidents have been reported?  If incidents did occur, how much money did the protocol lose? 

  • Weight: 10% 

  • Scoring guideline: 

    • 🟢 5 - No security incidents have been reported in the last 18 months resulting in the loss of any assets locked in the protocol. 

    • 🟡 3 - One security incident has been reported in the last 18 months resulting in the loss of less than 20% of all assets. 

    • 🔴 1 - One or more security incidents reported in the last 18 months resulting in losses exceeding 20% or greater of all assets. 

• Leverage 

  • Does the protocol offer its users leverage (introducing risk of socialized losses)? 

  • Weight: 10% 

  • Scoring guideline: 

    • 🟢 5 - No leverage offered. 

    • 🟡 3 - Max leverage is only offered up to 10x of (a user’s) total assets. 

    • 🔴 1 - Max leverage exceeds 10x total assets. 

• Bug bounty 

  • Does the protocol or a third party offer a bug bounty? Does the bounty cover a material share of the protocol’s TVL? 

  • Weight: 5% 

  • Scoring guideline: 

    • 🟢 5 - Active program and bounty is greater than 10% of TVL or at least $1M. 

    • 🟡 3 - Active program and bounty is greater than 3% of TVL or at least $300k. 

    • 🔴 1 - No active program exists. 

• Open source 

  • Is there a public code repo from the protocol team? Are the relevant smart contracts public? 

  • Weight: 5% 

  • Scoring guideline: 

    • 🟢 5 - A public software repository is available with history on commits, branches, and deployments. 

    • 🟡 3 - A public software repository is available and only includes history on deployments. 

    • 🔴 1 - No public software repository is available (repository is private). 

• Upgradeability 

  • Is access control documentation available from the protocol to disclose which aspects are upgradable or immutable? (Code upgrades can introduce bugs, and are therefore a risk factor.) 

  • Weight: 5% 

  • Scoring guideline: 

    • 🟢 5 - Both the contract documentation and the smart contract code state that the code is not upgradeable (immutable).  

    • 🟡 3 - All contracts are clearly labelled as upgradeable (or not). 

    • 🔴 1 - Information is not disclosed regarding the upgradability/ immutability of the code. 

• Multi-protocol/blockchain infrastructure 

  • Does the protocol interact directly or indirectly with third-party protocols? Is the protocol is exposed to multiple blockchains? 

  • Weight: 5% 

  • Scoring guideline: 

    • 🟢 5 - Documentation is available to clearly identify which blockchain(s) are utilized by the protocol and whether there is a reliance on any additional protocols to carry out any significant operations.  

    • 🟡 3 - Documentation specifies which blockchain(s) are utilized by the protocol but does not provide detail on the use of additional protocols utilized as part of any significant operations.  

    • 🔴 1 - Documentation is unavailable to disclose which specific blockchains are utilized. 

• Founding team 

  • Have the founding team members of the protocol publicly disclosed their legal names or onchain pseduonyms? 

  • Weight: 5% 

  • Scoring guideline: 

    • 🟢 5 - Founding team members are publicly disclosed and details are available to identify their roles and responsibilities with the protocol. 

    • 🟡 3 - Founding team members are publicly disclosed; however, there is no insight into their roles/responsibilities. 

    • 🔴 1 - Founding team members are unknown. 

• Investment 

  • Has the protocol has received outside investment (i.e. VC funding), and are the investors publicly disclosed? 

  • Weight: 5% 

  • Scoring guideline: 

    • 🟢 5 - Disclosures are available to confirm whether the protocol has received any external funding. If it has, detail is available to identify specific investors and total capital raised to date.  

    • 🟡 3 - Disclosures are available to confirm the protocol has received external funding; however, information is not available to identify specific investors, or capital raised.  

    • 🔴 1 - Disclosures are unavailable and investors cannot confirm whether the protocol has received any external funding. 

• Insurance/socialized losses 

  • Is there third-party insurance coverage available or a socialized loss mechanism in place for the protocol? 

  • Weight: 5% 

  • Scoring guideline: 

    • 🟢 5 - Insurance fund or socialized loss mechanism is available within the specific protocol. Documentation is available to detail the specific coverage available (including total assets maintained in the fund, eligibility to submit claims, and who verifies claims). 

    • 🟡 3 - Insurance fund or social loss mechanisms are not offered directly within the specific protocol; however, these can be purchased separately from a DeFi insurance provider. 

    • 🔴 1 - Neither an insurance fund nor social loss mechanisms nor third-party coverage is available. 

• Oracle(s) 

  • Does the protocol use sufficiently documented oracle(s)? 

  • Weight: 5% 

  • Scoring guideline: 

    • 🟢 5 - Documentation is available to identify the specific oracle utilized, if it uses one (and the smart contracts dependent on the oracles are identified). The timeframes of price feed updates (e.g. one per block added to the chain, once daily) are identified. 

    • 🟡 3 - The documentation identifies both source and timeframe of the oracles, but it does not provide specifics regarding smart contracts. 

    • 🔴 1 - The documentation only identifies the oracle’s source. 

• Age  

  • Has the protocol/contract has been active on mainnet for a material time? 

  • Weight: 5% 

  • Scoring guideline: 

    • 🟢 5 - main net has been active for over 2.5 years. 

    • 🟡 3 - main net has been active between 1 - 2.5 years. 

    • 🔴 1 - main net has been active for less than 1 year. 

6. Operational Risk Assessment – Weight (15%) 

The operational risk assessment focuses on an investor’s workflow, custodianship, and process risk. The evaluation begins with assessing whether a new wallet is required or a current wallet can be used, and if the investor’s current wallet infrastructure can support the required operations. The protocol’s whitelisting capabilities are then reviewed to determine if multi-actor approvals are possible before withdrawing funds or interacting with smart contracts, which is critical for enforcing access controls. Another key area is booking, the assignment of responsibilities for recording trades and managing reconciliation processes. The method of recording (manual or automated) and the segregation between operations and trading are considered crucial controls. Withdrawal limits imposed by the protocol, and whether these can be adjusted by either the investor or protocol to meet investor liquidity needs, are also evaluated. Monitoring capabilities, particularly the availability and interoperability of APIs, are reviewed to assess real-time risk reporting and operational scalability. Lastly, user interface quality is analyzed to ensure ease of use and institutional readiness. 

Components

• Wallet requirements and coin movements 

  • Is a new wallet required to manage digital assets sent to/maintained on protocol? Is the investor able to manage the wallet with its current infrastructure, or is a modification or development needed? Can a standard process to deposit/withdraw from the protocol be established? 

  • Weight: 25% 

  • Scoring guideline: 

    • 🟢 5 - Investor can generate a managed wallet which will be utilized for all coin movements/contract calls (to ensure such actions are approved in accordance with the investor’s vendor transaction authorization policy). 

    • 🟡 3 - Investor can at least utilize its own hardware, software wallets managed outside of third-party wallet solutions (and rely on in-house procedures to ensure segregation of duties is appropriately maintained for wallet access and token movements). 

    • 🔴 1 - Investor would have to rely on an independent third party to custody digital assets and to facilitate deposits/withdrawals. 

• Whitelisting 

  • Is whitelisting available as a protocol feature? 

  • Weight: 25% 

  • Scoring guideline: 

    • 🟢 5 - Whitelisting is enabled. At least two independent users are required to approve an address before initiating a withdrawal or performing a contract call (e.g. whitelisting which takes place in third-party wallet application). 

    • 🟡 3 - Whitelisting is enabled. At least one user must approve an address before initiating a withdrawal or performing a contract call. 

    • 🔴 1 - No whitelisting mechanisms are enabled to approve addresses. 

• Booking 

  • Can booking of trades be automated; if not, can trades manually booked by one team within the institution (e.g. trading) be verified by another (e.g. operations)?  

  • Weight: 25% 

  • Scoring guideline: 

    • 🟢 5 - All activity can be automatically booked within a centralized database, and booking does not require any manual intervention or adjustments by investor personnel. 

    • 🟡 3 - Appropriate investor team must manually book activity; however, specific transaction details can be recorded separately among multiple departments (e.g. trading and operations) to ensure segregation of duties. 

    • 🔴 1 - All activities must be manually booked by users within the same department. 

• Withdrawal limits 

  • Does the protocol impose withdrawal restrictions, and what are standard withdrawal limits? Can the limits be increased by the protocol team or by the investor? Scoring will vary based on exposure to the applicable protocol vis-a-vis entire portfolio protocol exposure. 

  • Weight: 10% 

  • Scoring guideline: 

    • 🟢 5 - Withdraw limits are defined by the protocol. Limits do not exceed investor’s total balance deposited in the protocol and allow investor to withdraw funds within a 24-hour timeframe.  

    • 🟡 3 - Withdraw limits are defined by protocol and allow investor to withdraw funds within a 72-hour timeframe.  

    • 🔴 1 - Withdrawal limits are not defined by protocol or investor is unable to withdraw its assets on demand. 

• Monitoring 

  • Does the protocol provide API documentation? Is the API interoperable with the investor’s trading technology? Can the investor’s risk and trading teams appropriately monitor risk on a live, ongoing basis? 

  • Weight: 10% 

  • Scoring guideline: 

    • 🟢 5 - Full set of API documentation is available. Transaction feeds can be configured within the investor’s live risk system to allow it to monitor activity and balances and assess risk in real time. 

    • 🟡 3 - Automated reports can be configured and sent to the relevant business heads to track activity and balances and assess portfolio risk.  

    • 🔴 1 - Real-time feeds and reports are unavailable. Reporting metrics are derived manually. 

• Interface 

  • Does the protocol have an easy-to-use interface and allow the investor to scale operations? 

  • Weight: 5% 

  • Scoring guideline: 

    • 🟢 5 - Interface is easily (and securely) accessible and user friendly. Detailed instructions are documented for performing all key functions required to interact with the protocol (including deposits, withdrawals, minting, claiming, etc.). 

    • 🟡 3 - Interface is accessible, but key functions are not clear or easy to perform. 

    • 🔴 1 - No user interface is directly accessible to firm personnel. 

Composite Scoring 

Scores range from 16 total points (highest risk) across the six domains to 100 (lowest risk). 

• Security – (20%) 

  • Onchain infrastructure security review and testing – (25%) 

  • Key management controls – (25%) 

  • Smart-contract review – (25%) 

  • Operational security controls – (15%) 

  • Audit logging – (10%) 

• Compliance – (15%) 

  • Compliance tool compatibility – (80%) 

  • Legal entity identification – (10%) 

  • Onboarding – (5%) 

  • Regulatory sandbox – (5%) 

• Financial – (15%) 

  • Transaction history – (35%) 

  • Economics (PnL) – (15%) 

  • Technology – (25%) 

  • New asset category – (15%) 

  • 1940 Act Impact – (10%) 

• Technology – (15%) 

  • Availability and slashing penalties (30%) 

  • Wallet/key infrastructure – (20%) 

  • Development – (20%) 

  • Segregation of duties – (20%) 

  • Multi-factor authentication – (10%) 

• Protocol – (20%) 

  • Whitepaper and software architecture – (20%) 

  • Treasury – (15%) 

  • Security incidents – (10%) 

  • Leverage – (10%) 

  • Bug bounty – (5%) 

  • Open source – (5%) 

  • Upgradeability – (5%) 

  • Multi-protocol/blockchain infrastructure – (5%) 

  • Founding team – (5%) 

  • Investment – (5%) 

  • Insurance/socialized losses – (5%) 

  • Oracle(s) – (5%) 

  • Age – (5%) 

• Operations – (15%) 

  • Wallet requirements and coin movements – (25%) 

  • Whitelisting – (25%) 

  • Booking – (25%) 

  • Withdrawal limits – (10%) 

  • Monitoring – (10%) 

  • Interface – (5%) 

Minimum Viable Criteria 

• Whitepaper and software architecture 

  • Is a whitepaper publicly available from protocol? Does the whitepaper have ample details regarding the protocol’s architecture? 

• Security audits  

  • Is a third-party audit available, or has an internal review has been performed by investor personnel? 

• Key management 

  • Does investor have the necessary processes and infrastructure to generate and custody keys? 

• Compliance monitoring tool 

  • Is investor able to use its compliance tooling to monitor all smart contracts that it interacts with? 

• Data  

  • Can the investor obtain a complete transaction log to monitor balances (i.e. funds deployed and withdrawn) and record activity in the financial statements, including balance sheet and PnL.

• Slashing penalties 

  • Slashing penalties have been assessed and are not overly punitive. 

Conclusion and Forward-Looking Guidance 

The purpose of this comprehensive framework is to enable a disciplined and replicable approach to DeFi operational risk management. By creating standardized criteria for evaluating protocols across the six risk domains outlined in this paper, institutions can measure and mitigate onchain protocol risk while capitalizing on the innovation and yield in decentralized systems. 

Galaxy operates using this exact framework in our own DeFi operations, which has kept our funds safe, and steered us clear of many protocols that subsequently suffered catastrophic hacks, rug-pulls, and other debacles.  

This framework is meant to be an adaptive, living document that evolves with the DeFi economy. As new threats, technologies, and standards emerge, the risk management process, and this framework, should be continually refined. We think this document serves as an appropriate baseline risk management procedure that is general enough to be extensible across L1s, rollups, and protocols, while leaving room for nuanced modifications.   

We anticipate that the DeFi and risk management communities will have profound suggestions for improvement that we may have not considered. Recognizing that, we welcome feedback on all elements of this paper, and the accompanying scorecard template. We have posted this paper to a Github repo where anyone can make a pull request with suggestions or modifications. Additionally, we are also posting a template scorecard and a sample completed scorecard for Aave, the largest DeFi protocol by TVL, so that the community can easily utilize the framework for themselves and even contribute to this public repository of protocol security reviews. 

Thinking ahead, we have to acknowledge there are limits to this framework. It is focused on the operational risks of interacting with a protocol and is only a part of a comprehensive institutional-level risk management framework for operating in DeFi. We have not scored every protocol in DeFi, but our experience to date tells us that the distribution of ratings is not uniform, and that DeFi exploits and mishaps are common. The minimum weighted score a protocol can receive under the SeC FiT PrO framework is 16%.  The vast majority of DeFi protocols we have scored are <50%, with a proud few >85%. Assuming operational risk remains distributed unevenly across protocols, with a small tail scoring well and the vast majority scoring poorly, we recommend against broad protocol diversification until better risk management tools and DeFi insurance markets are available.  

SeC FiT PrO is purpose‑built to compare the relative risk of individual DeFi protocols; it is not intended to benchmark those risks against traditional assets, such as middle market bonds. In a forthcoming piece, we will expound on the market risks and portfolio construction considerations for a DeFi portfolio manager or risk manager operating across many protocols. Backed by a robust data-driven analysis, the next release will give managers the necessary tools to quantify and measure smart-contract default risk, hedge against it, and fully incorporate DeFi positions into traditional portfolios.