# Soft factors and structural resilience

Technical security and economic design are critical in DeFi, but they are not the only elements that determine whether a protocol survives stress.

Behind every decentralized protocol are real teams, governance communities, and development processes. When problems occur — and in DeFi they eventually do — the way these human and organizational structures respond often determines whether the situation is resolved quickly or escalates into a major failure.

For this reason, Shift evaluates a set of [soft factors](https://medium.com/@SHIFT_DeFi/brains-bucks-and-bug-bounties-the-soft-side-of-defi-risk-e2ec723ba051) alongside technical and economic risks. These factors do not usually cause immediate losses on their own, but they strongly influence how resilient a protocol is under pressure.

Among the key indicators we examine are:

**Total Value Locked (TVL) trends**

TVL reflects how much capital users have entrusted to a protocol. Large and stable TVL often signals market confidence and deep liquidity. At the same time, sudden drops in TVL can indicate deteriorating trust or emerging risk events.

**Time since launch**

Protocols that have operated through multiple market cycles — including periods of extreme volatility — tend to reveal their weaknesses over time. A longer operational history provides more data on how the system behaves during stress.

**Funding and backer quality**

Well-funded projects with reputable investors typically have greater resources for development, security reviews, and long-term maintenance. Limited funding or unclear backing can raise questions about the project’s ability to respond to crises.

**Team transparency and track record**

Protocols led by publicly known teams with verifiable experience tend to inspire more confidence than projects operated by anonymous or unproven developers. While anonymity is common in crypto, it can also increase operational risk if accountability mechanisms are weak.

**Governance structure and execution** 

The effectiveness of governance depends not only on participation, but on how decisions are made and enforced.

In practice, DeFi protocols operate across different governance models:

* No DAO\
  Decisions are made entirely by the core team, with no formal community governance.
* Off-chain governance with centralized execution\
  Proposals are discussed and voted on by the community (e.g., forums or snapshot), but implementation is controlled by the team. This creates a gap between governance outcomes and actual execution
* Fully on-chain governance\
  Voting and execution are handled directly on-chain. Approved proposals are enforced automatically, without reliance on a central party.

**Timelocks and safeguards**

Well-designed governance systems include additional safeguards such as timelocks — delays between a proposal being approved and executed.

These delays provide time to:

* review changes
* assess potential risks
* exit positions if necessary

Audit frequency and incident response history

Security audits are an important signal of technical maturity. However, the presence of audits alone is not enough. Shift also examines how teams have historically responded to vulnerabilities or incidents. Rapid and transparent responses often indicate a stronger operational culture.

Taken together, these soft factors help form a broader picture of a protocol’s structural resilience — its ability to withstand unexpected stress and recover from problems when they occur.

In many real-world cases, the difference between a contained incident and a catastrophic loss comes down not only to the code, but to the people and processes behind it.

<br>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.shiftdefi.com/user-docs/the-risk-framework/risk-assessment/soft-factors-and-structural-resilience.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.