Building Financial Products on DeFi Infrastructure

DeFi rails are powerful and fragile at the same time. Here's what we've learned building on top of them.

What "DeFi infrastructure" actually means

When we say we're building on DeFi infrastructure, we mean the stack of protocols and primitives that provide core financial functions in a decentralized way: token standards, liquidity pools, price oracles, bridging protocols, and settlement layers. Each of these has properties — composability, transparency, permissionlessness — that make them valuable as building blocks. Each also has limitations that only become apparent when you push them hard.

The composability problem

Composability is DeFi's superpower: protocols can plug into each other without permission, creating systems that no single team designed. It's also a source of systemic risk. When a component you depend on has a vulnerability, the exploit doesn't stay contained to that protocol. It propagates through everything built on top of it.

The 2022-2023 period demonstrated this repeatedly. Protocols that had been audited and running without incident for years failed catastrophically because of interactions with other protocols no one had thought to model. Building on DeFi rails means accepting this risk and designing defensively against it — careful dependency selection, circuit breakers, and insurance mechanisms.

Gas optimization as product design

Every on-chain operation costs gas. In a trading application, this isn't just an infrastructure cost — it directly affects trading economics. A protocol that requires $5 in gas to open a position is unusable for traders working in smaller sizes. Gas optimization isn't a nice-to-have; it's a requirement for having a viable product.

The choices compound: storage layout, function visibility, data packing, loop optimization. Each decision made during protocol design has a gas cost implication. We spent significant engineering time on this before launch and have continued to optimize. The result is a system where the on-chain operations are cheap enough that they don't eat meaningful portions of trading margins.

The oracle dependency

External price feeds are the point where DeFi and the real world connect. They're also the most manipulable component in most DeFi systems. We've seen oracle manipulation attacks cause hundreds of millions in losses across the space. Getting oracle design right isn't optional for a trading protocol — it's foundational.

Our approach (Chainlink + TWAP hybrid) is conservative by design. There are faster and cheaper oracle configurations. We chose depth and manipulation resistance over speed, because in a perpetual exchange, the oracle failure mode is catastrophic in ways that a minor execution speed improvement isn't worth risking.

Upgrade risk in deployed contracts

One of the tensions in DeFi protocol design is between upgradeability and trustlessness. An upgradeable contract can be patched when bugs are found, which is clearly valuable. But upgradeability also means the operator can change the rules after the fact, which is exactly the kind of trust assumption DeFi is supposed to eliminate.

Our approach is a timelocked governance model for protocol upgrades. Changes must be proposed, and a mandatory delay passes before they take effect. This gives users time to exit positions before changes they disagree with become active. It's not a perfect solution, but it's a meaningful constraint on the protocol team's ability to change the rules without warning.

The bridge problem

Cross-chain bridges are consistently the most exploited component in DeFi. Since 2021, more than $2 billion has been stolen from bridge protocols across multiple chains. The attacks are varied — smart contract bugs, validator collusion, oracle manipulation — but the underlying issue is always the same: bridges involve trust assumptions that are hard to eliminate and high-value enough to attract sophisticated attackers.

The practical implication for a trading protocol is to minimize bridge exposure. Where possible, support native assets on the chain where the protocol operates rather than wrapped representations that require bridge infrastructure. Where bridged assets are necessary, be explicit about the additional risk and use battle-tested bridges with meaningful track records.

In our experience, the most dangerous position a DeFi team can take is "we've been audited and we're safe." Audits catch bugs that auditors are paid to look for. They don't catch the novel attack vectors that will appear over the next 12-24 months as the protocol's TVL grows and it becomes a more attractive target. Security is ongoing, not a milestone.

What we'd do differently

If we were starting from scratch, we'd invest earlier in formal verification of the core margin and liquidation logic. Formal verification proves mathematical properties of the contract code rather than testing specific scenarios. It's expensive and slow, but for the handful of functions that determine whether traders' money is safe, the investment is worth it.

We'd also design the oracle integration more modularly from the start. The current architecture works, but switching oracle providers or adding a second source requires more refactoring than it should. Modularity in the oracle layer is a real engineering value, not just a nice-to-have.