Decentralization was the beginning. Call it 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.

A conventional LTV model cannot fully neutralize delta. If staked ETH has a 90% LTV, there remains a 10% balance-sheet requirement that cannot be eliminated merely by hedging the price exposure. You need the system to recognize 100 against 100.

Netting configurations can approximate that result, but they cannot fully eliminate the residual requirement. Equity accounts can, because they assess the account’s actual equity, including P&L and offsetting positions such as staked ETH against ETH.

That is what makes ftUSD work.

We take the USDC and USDT deposited into it as collateral, borrow ETH against that collateral, swap the borrowed ETH into staked ETH, and post the staked ETH as additional collateral. The staked ETH and ETH legs are designed to offset one another, while the underlying stablecoin collateral continues to support the position.

Under our modeled parameters, the design can support up to roughly eight turns.

We are operating at roughly 1.5 times today, deliberately below modeled capacity while the system is young and available liquidity is still developing.

At higher utilization, the economics depend on the spread. If staked ETH earns 2.4% and ETH borrowing costs approximately 2.1%, each turn contributes roughly 0.3 percentage points of carry before other costs. The stablecoin side may add another 3.2% to 4%.

The resulting return therefore changes with leverage, borrowing costs, staking yields, liquidity and execution. It is a design capacity, not a fixed return or a promise.

Our perpetual markets are not live yet. Once they are, the standard carry trade can become a second source of return rather than leaving the system dependent on a single mechanism.

One design choice I am particularly proud of is our RFQ-based liquidation process.

Rather than allowing a liquidator to repay debt and take a fixed portion of collateral, the system sends out an RFQ and fills the best bid. During recent market stress, we have processed a meaningful number of liquidations, and in almost all cases the liquidatable debt was repaid dollar for dollar without a haircut to the user.

It may sound incremental, but these design choices compound.

None of this fits a pure version of the 2020 definition of decentralization. It reflects what we are: a company operating financial infrastructure onchain, with the disclosure and controls that model requires.

Capital evaluates outcomes

I am often asked whether institutions will take onchain finance seriously, usually as though sentiment or terminology will decide the outcome.

In practice, the core questions are whether a system offers better risk-adjusted outcomes, does more than the alternative, manages risk transparently and costs less.

Those fundamentals matter more than the label. Public crypto discourse and institutional allocator diligence often focus on very different things.

Call it onchain finance. The discipline is still finance; the infrastructure is now onchain.