What a defi development company handles beyond Web3 delivery: protocol safety, solvency, oracle risk, audit readiness, and incident response.
A DeFi development company can be seen as shipping protocol logic that safely holds, routes and pays out users' funds in adverse situations. As contracts control pooled funds, the team behind them is accountable for the financial behavior of the said code in scenarios of market swings, low liquidity and failed dependencies.
This scope is actually narrower than the scope of generic Web3 engineering team projects, yet far heavier. The team of developers defines the invariants of the smart contracts, encodes them correctly, tests them thoroughly for various edge cases, including hostile ones, and ensures that the financial protocol remains solvent in the expected operating range. If a swap path for example breaks in a dApp, this only leads to a bad user experience. However, if a collateral rule, an oracle read, an accounting edge case etc. breaks in a financial protocol, the resulting imbalances could be irreversible.
Delivering a Protocol is fundamentally different than delivering a front end. Here's why: while a front end bug can immediately block a deposit, a protocol bug can economically misprice collateral, mint bad debt, or allow a single actor to drain value from a pool. This fundamentally changes the engineering standard from completing features to preventing losses.
A strong Web3 engineering team can build wallets, dashboards and integrations with good product discipline. A protocol team on the other hand requires the same product discipline, but also adversarial testing, formalized assumptions, stricter deployment procedures and a review process that treats every external call, every rounding of numbers and every governance decision as a money movement surface.
There are several key aspects of a lending market's setup (pool parameters, curve selection, fee structure, etc.) which are actually financial model choices to keep a protocol liquid, solvent, and usable in the case of one-sided order flow. A common practice of copying other protocols' numbers to set up a new market, makes for efficient-looking work, but that's how teams of developers end up with financial models that have been set up for completely different assets under different volatility regimes with completely different depth distributions.
A lending market with borrowed collateral factors from a blue chip asset will become fragile very quickly as it tries to support thinner pairs. AMM curves copied from large stable routes will overpay arbitrageurs or trap liquidity in volatile asset paths. Fees that look competitive in calm times will not be enough to compensate liquidity providers in times of sharp movement, and as such the pool will lose most usable depth exactly when pricing pressure rises.
The work should look more like model review than feature assembly.
| Design choice | What must be modeled | What breaks when copied blindly |
|---|---|---|
| Collateral parameters | drawdown, liquidation path, slippage | bad debt after fast moves |
| AMM curve | inventory sensitivity, arbitrage cost | toxic order flow drains one side |
| Fee structure | LP compensation across volatility states | liquidity exits or stops tightening |
| Incentive design | depth quality, duration, mercenary flow | shallow TVL that disappears under stress |
This turned out to be a fundamental issue for the Kaspa DeFi work at DESH as well. Early on in the work, the chain specific liquidity realities had to be factored into the parameter setting for the model before any interface work could be done. The end result had to form a protocol that would be supported by the real market, as opposed to the 'paper' market presented by a reference implementation that was copied for work on the new chain.
Price manipulation is an attack class that unit tests rarely expose on their own. A function can be syntactically correct, revert correctly, and yet be extremely dangerous by trusting a price that is stale, biased or easily moved. Thus oracle review needs to be conducted as and when reviewing contracts, not after.
Single source dependency is the first warning sign for oracle risk. A single provider stalling or reporting an outlier needs to be handled with a clear behavior choice (e.g. reject the action, fall back to a bounded secondary source, restricted mode of operation). Low liquidity pairs used as reference for pricing need to be screened for price manipulation as well. In particular, a competent team will check whether the reference market can be cheaply manipulated in order to attack borrow, mint or liquidation logic of the protocol. Additionally, update latency of the feed is important. A feed that is acceptable for a dashboard might not be acceptable for collateral checks if price freshness is not enforced. The documentation of Chainlink's price feeds is useful in this regard, as it clearly states the assumptions of the oracle about heartbeat and deviation.
Specific ways to handle the risks of oracle data include source diversity as required, screening of the liquidity of the reference markets, certain thresholds for freshness, bounds checks, design of the fallback state(s), and simulation of the conditions that occur when the chain is very congested, as opposed to the typical block. Using Chainlink is not a sufficient answer.
Even if a smart contract's logic is perfectly implemented according to a given specification, that does not necessarily mean the underlying specification for a protocol's smart contract(s) is safe. There are many ways that even perfectly coded safe smart contract specifications can allow for many varieties of toxic borrowing, griefable liquidations, fee leakage, and even more dangerous forms of a reflexive liquidity collapse. Thus, smart contract development for a protocol needs two reviews instead of collapsing both reviews into one.
The first review tries to verify whether a given piece of code actually does what its authors claim to have implemented, whereas the second review attempts to verify whether the given implementation's claims are in fact economically durable. Hence, it follows that these two reviews are best performed by two different individuals with different skill sets. For instance, the first review of the given smart contract code for a money making protocol would be mostly centered around storage layout, reentrancy surfaces, and mathematical paths that the code takes, whereas the second review would focus on things like the given contract's monetary incentive structures, its sensitive parameters, and finally, the possible profit that a successful "attacker" could extract from the said contract. A vendor that provides only the first review can still deliver a contract that passes all tests and fails in a live market.
Audit readiness refers to a protocol being describable, testable, and reviewable prior to auditor involvement. If the team is at audit with shifting rules, unknown edge cases, and failure path tests missing for certain failure cases, the auditor gets ambiguity rather than a system.
A protocol team should arrive at a security audit with four concrete artifacts already in place:
Even with contracts live on mainnet, there is operational risk which also requires on chain monitoring. A protocol holding pooled funds needs monitoring for balance changes (abnormal), borrow utilization (abnormal), liquidation spikes, oracle staleness, admin action alerts and failed keeper activity.
The upgrade design of a system also introduces a number of governance tradeoffs. Strong privileged control helps contain live issues, but the same privilege becomes a risk surface of its own. So for example the upgrade of a single address via a proxy such as defined in EIP-1967 could be considered to be a 'legible' upgrade. But then the question arises of who can upgrade, how quickly, with what delay and what can be paused without trapping other users. A simple 'pause switch' needs to be considered and tested. Having a multisig is not in itself a control plan.
Launch phase engineering on Ephemeral at DESH was actually harder than deploying the contracts to go live in the first place. There were lots of post launch controls, observability and runbook logic that needed to be wired up by the operators so that in the event of reality differing from our test cases, the operators could act with some level of precision.
Review their methodology for setting pool parameters and ask for evidence that was used to approve the pool parameters. A poor response would be "we benchmark against leading protocols in the space" or "we can start with setting pool parameters to standard values". Note that standard values for pool parameters were likely set by someone else analyzing asset behavior, a liquidity profile, and liquidation depth. Ask about oracle stalls, thin reference markets, and congestion. A poor response would be "the oracle provider is battle tested and will work for us" or "the auditor will flag any issues". Note that these responses outsource dependency design to reputation rather than actually analyzing system behavior.
How do they review for economic soundness versus code correctness? If they say that their senior Solidity engineer can cover both, then that means that nobody is doing distinct market risk review. What artifacts do they prepare for the audit? If they say that they write tests and then send the repo to the auditor, then that means that the auditor will have to infer the intended behavior for the vast majority of the review, which would be a waste of review depth on basic reconstruction. Ask what their incident plan covers after launch: pause scope, upgrade authority, monitoring thresholds, and who is cleared to act at what severity. A plan to monitor the chain and pause if needed is not a plan, it is a promise made before the first real incident.
Put this to the test with a real protocol. Book a Call with DESH.
For products mainly focused on custody, signing, account abstraction or recovery, wallet architecture is the better resource than a protocol focused engagement.
A matching engine, order book, custody flows or market operations-based product would best be served by an exchange development resource.
Can a strong audit compensate for a weak protocol design phase?
No. An audit can identify many problems, but the core of all problems (missing market assumptions, undefined invariants, missing failure state tests etc.) has to be identified before review even starts.
When should oracle design be finalized?
Before contract interfaces harden. Oracle design is a core aspect of the protocol design (e.g. oracle freshness, fallbacks, manipulation assumptions). These are design inputs that are much more central to the core design than integration details.
Is upgradability always required for DeFi protocols?
Upgradability is not required for all DeFi protocols, but if they do have the option for upgradability, then governance (speed, scope, pause) will also need to be reviewed.
What is the clearest early sign that a vendor lacks protocol depth?
They speak about audits, frameworks, and chain experience before they speak about solvency, invariant design, liquidity assumptions, and oracle failure behavior. That ordering usually reveals how they think about risk.
