Why DeFi Is Evolving Into Onchain Finance

The following is a guest post and opinion piece by Andre Cronje, Founder and CEO of Flying Tulip.

Decentralization was the starting point for DeFi. But it is no longer the complete operating model for most protocols, and our language should evolve with the industry.

This is not an argument against decentralization. It is an argument for being precise about where it exists, where operational responsibility remains, and what trust assumptions follow.

I say that as someone who spent years building toward the opposite ideal. Yearn Finance launched with no team allocation, no foundation and no pre-mine. Everything went to protocol users. The aspiration was similar to Bitcoin’s: minimize dependence on the founder and let the community carry the system forward. The original Yearn protocol ran entirely onchain. There was no offchain server supporting its core operation. The only thing I paid for was the domain name.

That model would be difficult to sustain today. Users now expect an identifiable team to maintain the product, support operations, manage risk and continue creating value. Tokens are also increasingly evaluated first as economic exposure and only then as utility. The early user base was smaller and more technically immersed; today’s is broader, and the product has evolved with it.

Consider what a modern protocol requires in practice. It needs a reliable front end, support channels, offchain infrastructure, and keepers and liquidation bots that teams often operate themselves rather than placing entirely onchain. Each of those functions has a real operating cost.

It also needs a team that can be paid, remain through a vesting term and build beyond a two-year horizon. None of that is contained in a smart contract. The result is that many protocols increasingly resemble operating companies: they charge fees, employ teams and maintain systems over time.

Immutability is a design choice, not a doctrine

When teams ask me whether contracts should be immutable or upgradeable, I generally recommend upgradeability for complex financial systems, provided the governance and security model is designed around that fact.

Immutability remains valuable for simple, bounded systems. In a financial system that must respond to changing markets, integrations and threats, however, it can also become a constraint.

That choice carries serious responsibility. Upgradeability creates one of the largest threat surfaces in a protocol. A single developer key with unilateral authority to upgrade contracts can become a system-wide point of failure. A conventional smart-contract audit cannot eliminate that operational risk.

An audit is not a security strategy

Audits matter and remain necessary, but they are only one layer. The industry still gives them more attention than infrastructure security, key management, circuit breakers and real-time outflow monitoring.

Those controls take time to build. They also introduce friction, which teams are understandably reluctant to add. They are still essential.

At Flying Tulip, we use multiple layers of circuit breakers. When a user requests a withdrawal, the request enters a queue and becomes claimable six hours later.

I have used the system myself, checked Etherscan, seen the funds sitting in the circuit-breaker contract rather than my wallet, and briefly wondered what had happened before remembering the delay. I understand the friction firsthand. It is still worth it.

Circuit breakers are a feature, not a defect. Repeated eight-figure losses across the industry continue to reinforce that case.

Getting this right is not only about having multiple layers. It is also about separating authority.

Anything in our system that can move money sits behind a timelock and a multisig. Anything that can pause or delay an outflow cannot sit behind the same timelock, because an emergency control that requires 72 hours is not an emergency control.

That separation must exist at the base-code level. It needs to be designed in from the beginning.

Your counterparty is not always a smart contract

The more consequential issue, however, is not technical.

Much of onchain finance is still described using the trust assumptions of early DeFi, where users could treat the smart contract as their principal counterparty.

Curated vaults illustrate the distinction. They are often understood through the conceptual model of a 2020 Yearn vault: your exposure is to the contract and the protocols into which it deposits.

In many modern structures, the exposure is broader. The effective counterparty may include a curator, an offchain credit facility, a non-liquidatable onchain RWA or an IOU.

That can still be a sound product. The important point is that users understand what they are actually exposed to.

In most cases, this reflects an industry in transition rather than bad intent. Teams originally formed around software are learning to operate full financial businesses, with the disclosure, governance and controls that entails.

But risk emerges wherever a product’s presentation does not fully match its actual trust and counterparty model.

The same principle applies to tokens. Regulated public markets generally impose extensive expectations around disclosure, compliance, governance and financial reporting. Tokens that trade publicly are often evaluated by buyers through a similar economic lens.

If we seek the credibility and liquidity of public markets, we should be prepared to meet a comparable standard of transparency.

Applying that standard to ourselves

Flying Tulip’s margin accounts are equity-based rather than LTV-based. That may sound like a technical detail, but it is central to the design.