How We Evaluate Risk
Before we allocate a single dollar, we verify. Here's what we check and why it matters for your capital.
Qualitative First
Most risk frameworks start with numbers: TVL, APY, audit count. We start with questions that numbers can't answer.
Who controls the contracts? A protocol can have perfect code and still lose everything if the wrong person holds the keys. We map admin powers, multisig configurations, timelocks, and upgrade paths before looking at yields.
What happens when things break? Every protocol will face stress eventually. We evaluate how teams responded to past incidents, whether they have documented procedures, and if they can actually execute under pressure.
Numbers come after. Once we understand the qualitative risk surface, we set parameters and allocations that reflect what we actually know - not what dashboards tell us.
"Yield without risk curation is gambling. We're not here to chase the highest APY. We're here to protect capital and capture yield that makes sense given the risk."- Clearstar approach
Bridging TradFi to DeFi
Traditional finance operates on trust, regulation, and institutional accountability. DeFi operates on code, transparency, and verifiable on-chain data. These aren't incompatible - they're complementary. But someone needs to translate between them.
Clearstar acts as that bridge. We apply institutional risk standards to DeFi protocols, creating the due diligence layer that traditional capital requires. Banks, asset managers, and fintechs can't deploy into protocols they haven't vetted. We do that vetting using methods they understand.
Our framework maps directly to traditional risk categories: counterparty risk becomes governance and multisig analysis. Operational risk becomes team assessment and incident response review. Market risk becomes oracle and liquidity evaluation. The concepts translate - the implementation is on-chain.
What this means for institutions: You get exposure to DeFi yields without building internal DeFi expertise from scratch. You get risk documentation in formats compliance teams can work with. You get continuous monitoring that flags issues before they become incidents.
What this means for DeFi: Institutional capital brings stability, liquidity, and legitimacy. When banks and fintechs can safely deploy into DeFi, the entire ecosystem benefits from deeper markets and broader adoption.
Institutional Standards
Due diligence that meets the requirements of regulated entities and compliance frameworks.
Documentation
Risk assessments, audit trails, and reporting that compliance teams can actually use.
Continuous Monitoring
Not a one-time assessment. Ongoing surveillance of positions, protocols, and market conditions.
Two-Way Value
Institutions get safe DeFi access. DeFi gets the capital and legitimacy institutions bring.
Our Due Diligence Process
Our framework operates in stages. Every opportunity goes through Initial Screening first, then General Due Diligence (applies to all), followed by parallel specialized tracks based on what's being evaluated: assets, protocols, or blockchains. Finally, approved positions enter Continuous Monitoring.
Before any deep analysis, we assess whether an opportunity fits our mandate. The goal is to filter quickly - most opportunities don't make it past this stage. We use a standardized intake form to ensure consistent evaluation.
Intake Form Sections
Every opportunity that passes screening goes through these six areas. These apply universally - whether we're evaluating an asset, protocol, or blockchain.
1. Governance and Access Control
- Contract ownership and admin key structure
- Multisig configuration and signer verification
- Timelock duration for upgrades
- Emergency powers and their triggers
- On-chain vs. off-chain governance
2. Smart Contract Security
- Audit history and firm reputation
- Critical findings and remediation status
- Time in production without incidents
- Code complexity and attack surface
- External dependencies and composability risk
3. Oracle Security
- Price feed source and methodology
- Single oracle vs. multi-oracle setup
- Staleness thresholds and fallback logic
- Manipulation resistance mechanisms
- Circuit breakers and deviation limits
4. On-Chain Financial Audit
- TVL verification against on-chain data
- Reserve backing and collateral ratios
- Fund flow analysis and wallet separation
- Treasury vs. user fund segregation
- Historical solvency verification
5. Team Reputation and Transparency
- Founder and core team background
- Track record in previous projects
- Incident response history
- Communication quality during stress
- Legal entity structure and jurisdiction
6. Economic Design
- Yield source: real revenue vs. emissions
- Token incentive sustainability
- Fee structure and protocol revenue
- Liquidation mechanics and bad debt handling
- Economic attack vector analysis
When evaluating specific assets for collateral or yield positions, we apply this framework. Different asset types (stablecoins, LSTs, LRTs, governance tokens, LP tokens) have different risk profiles, but all go through the same assessment areas.
1. Asset Mechanism and Design
- How the asset maintains its value or peg
- Redemption mechanics and guarantees
- Underlying backing and collateral structure
- Rebasing vs. reward-accruing design
2. Ownership and Supply Distribution
- Token concentration and whale analysis
- Vesting schedules and unlock events
- Team and investor allocations
- Supply cap and inflation mechanics
3. Liquidity and Market Depth
- DEX and CEX liquidity across venues
- Slippage at various trade sizes
- Historical liquidity stability
- Market maker presence and reliability
4. Volatility and Price Behaviour
- Historical price volatility metrics
- Correlation with major assets
- Behaviour during market stress events
- Peg deviation history (for stablecoins)
5. Smart Contract Implementation
- Token contract audit status
- Proxy patterns and upgradeability
- Admin functions and permissions
- Blacklist or freeze capabilities
6. Incentives and Sustainability
- Source of yield or rewards
- Emission schedule and runway
- Dependency on token price
- Long-term viability of incentive model
7. Dependencies and External Risks
- Oracle dependencies for pricing
- Cross-chain bridge exposure
- Reliance on external protocols
- Single points of failure
8. Regulatory and Issuer Risk
- Issuer jurisdiction and legal status
- Regulatory compliance posture
- Censorship and freeze risk
- Counterparty exposure to issuers
Protocol-level analysis focuses on the system itself. Different protocol types (lending markets, DEXs, yield aggregators, derivatives platforms) have different mechanics, but we apply consistent assessment criteria.
1. Protocol Design and Mechanics
- Core mechanism and how it generates yield
- User flow and interaction patterns
- Capital efficiency model
- Innovation vs. battle-tested design choices
2. Proven Model and Lineage
- Fork vs. original implementation
- History of the underlying model
- Known vulnerabilities in similar systems
- Departures from proven designs
3. Fee Structure and Economic Model
- Protocol fee breakdown and distribution
- Revenue sustainability without incentives
- Fee competitiveness vs. alternatives
- Value capture mechanism for stakeholders
4. Operational History and Stress Performance
- Time in production and TVL history
- Behaviour during market volatility
- Past incidents and response quality
- Uptime and reliability track record
5. Liquidation and Risk Curation
- Liquidation mechanism and incentives
- Bad debt handling and socialization
- Risk parameters (LTV, CF, caps)
- Historical liquidation performance
6. Dependency Chain
- Oracle dependencies and fallbacks
- External protocol integrations
- Bridged asset exposure
- Infrastructure dependencies (RPC, indexers)
7. Integration and Composability Risk
- How the protocol composes with others
- Flash loan attack surface
- Reentrancy and callback risks
- Integration audit coverage
8. Governance Attack Surface
- Governance token distribution
- Vote buying and bribery exposure
- Flash loan governance attacks
- Proposal threshold and timelock adequacy
Before deploying on any chain, we evaluate the infrastructure itself. L1s, L2s, and sidechains each have different trust assumptions and risk profiles.
1. Decentralisation and Validator Set
- Number and distribution of validators
- Stake concentration and Nakamoto coefficient
- Geographic and jurisdictional diversity
- Validator selection and rotation mechanism
2. Consensus Mechanism and Security Model
- Consensus algorithm and finality guarantees
- Attack cost and economic security
- Slashing conditions and penalties
- Known theoretical vulnerabilities
3. Client Diversity and Implementation Risk
- Number of client implementations
- Client distribution among validators
- Bug bounty and security audit coverage
- Upgrade coordination process
4. Uptime and Reliability
- Historical uptime and outage frequency
- Block time consistency
- Incident response track record
- Recovery procedures and testing
5. Maturity and Ecosystem Development
- Time since mainnet launch
- Developer activity and tooling quality
- DeFi ecosystem depth and diversity
- Bridge and interoperability options
6. Validator Behaviour and Centralisation Risk
- MEV extraction practices
- Censorship incidents or capabilities
- Staking pool concentration
- Foundation/team influence over validators
7. Bridge Security and Cross-Chain Risk
- Canonical bridge design and trust assumptions
- Bridge audit and incident history
- Third-party bridge exposure
- Wrapped asset backing verification
8. Regulatory and Jurisdictional Risk
- Foundation and team jurisdiction
- Validator jurisdiction concentration
- Regulatory posture and compliance
- Censorship capabilities and policies
Due diligence doesn't stop at deployment. We monitor all positions continuously using automated systems that flag issues by severity. Only critical alerts trigger automated exits - everything else is reviewed by the team.
Alert Severity Levels
🔴 Critical
Active exploit, confirmed hack, or imminent fund loss. Triggers automated exit.
🟠 High
Significant risk indicator requiring immediate team review. May trigger manual position reduction.
🟡 Medium
Notable change or concern requiring attention within 24 hours. Documented and tracked.
🟢 Low
Informational alerts, routine changes, or minor deviations. Logged for pattern analysis.
Monitoring Stack
Each assessment area receives a grade. The grades translate to numeric scores for composite calculations. An F grade in any critical area is an automatic disqualification.
| Grade | Score | Meaning | Implication |
|---|---|---|---|
| A | 1.0 | Excellent | Best-in-class for this area. No concerns. |
| B | 2.0 | Good | Above average. Minor areas for improvement. |
| C | 3.0 | Adequate | Meets minimum requirements. Notable concerns documented. |
| D | 4.0 | Poor | Below standard. Requires compensation in other areas or position limits. |
| F | 5.0 | Failing | Automatic disqualification. No allocation regardless of other scores. |
Access our complete quantitative and qualitative risk framework →
Due Diligence Areas
Every protocol we allocate to goes through a structured review. Here's what we verify:
Governance & Access
Who can change things, and how fast can they do it?
- Who controls the contracts and can they make changes without delay
- Multisig setup: how many signers, who are they, what's the threshold
- Timelock duration for upgrades and parameter changes
- Emergency powers and who can trigger them
Smart Contract Security
Has the code been reviewed, and were issues fixed?
- Audit history and whether critical findings were fixed
- Time in production without major incidents
- Complexity of the codebase and attack surface
- Dependencies on external contracts or libraries
Oracle Setup
How does the protocol know what prices are?
- How price feeds work and what happens if they fail
- Single oracle vs. multiple sources
- Staleness thresholds and fallback mechanisms
- Manipulation resistance and circuit breakers
On-Chain Verification
Does reality match what's reported?
- On-chain verification that reported TVL matches reality
- Reserve backing and collateral ratios
- Fund flows and wallet separation
- No commingling of user funds with treasury
Team & Operations
Can the team actually execute when it matters?
- Team experience and track record
- Response to past incidents
- Communication during stress
- Operational procedures and documentation
Economic Design
Is the yield sustainable or dependent on incentives?
- Source of yield: real revenue vs. emissions
- Token incentive sustainability
- Protocol revenue and fee structure
- Liquidation mechanics and bad debt handling
Automatic Red Flags
Some things immediately disqualify a protocol, regardless of yield or reputation:
🚫 We don't allocate if:
- Evasive communication - Avoiding questions or giving inconsistent answers signals deeper problems
- Unclear admin rights - Unverified multisigs, unknown signers, EOA admin keys, or hidden upgrade powers
- Commingled assets - Mixing user funds with treasury makes solvency impossible to verify
- Untraceable fund flows - If we can't follow reserves and collateral, we can't assess risk
- Refusal to address issues - Risk is normal; refusing to acknowledge or fix it is not
- No timelocks on critical functions - Instant upgrades mean instant rug potential
How We Work
Our due diligence follows a consistent process. Here's what happens before capital moves:
Initial Screening
Quick check for obvious red flags. Audit existence, team visibility, basic contract review. Most protocols get filtered out here - we're looking for reasons to say no early.
Deep Dive
Full review across all DD areas. Contract analysis, governance mapping, oracle verification, team assessment. We talk to teams directly when needed.
Parameter Setting
Based on findings, we set risk parameters: allocation caps, LTV limits, oracle bounds, exposure limits. Conservative by default - we can always increase later.
Deployment
Capital deployed within parameters. Initial positions are smaller. We scale up as we gain confidence from live monitoring.
Continuous Monitoring
DD doesn't stop at deployment. We monitor positions continuously: price divergence, liquidity changes, governance proposals, team changes. If conditions deteriorate, we reduce exposure.
See the yield opportunities that have passed our framework →
Want the full framework?
Our complete documentation covers QRA, smart contract DD, operational due diligence, and more.
Read the DocsOr see where we deploy capital →