Protocol & DeFi Systems: how we design economics, settlement and failure paths

The protocol problem

A lending contract can calculate collateral ratios correctly while relying on a liquidation buyer who cannot receive the collateral. A vault can report positive asset value while lacking the cash to honour withdrawals. A prediction-market router can buy an opposing position that resolves under different rules and leaves the user exposed. In each case, the contracts may execute as written while the product fails its economic promise.

We start by defining that promise and the conditions required to keep it. Which assets back each claim? Who supplies liquidity when positions close? What happens when a price is unavailable, a liquidation cannot settle or an external venue stops responding? These answers determine contract states, accounting and operational authority.

Protocol development connects those decisions to enforceable rules. The system must preserve its accounting through ordinary activity, adverse market conditions and intervention. A pause can stop additional exposure; it cannot replace missing collateral or recover funds already lost.

What we build

We build protocol contracts together with the services needed to operate them. The boundary depends on the product: lending markets, liquidity vaults, prediction markets and execution systems have different assets, liabilities and settlement conditions.

The architecture identifies which rules contracts enforce synchronously and which depend on external actors. A keeper can submit a liquidation, but the contract must still verify its conditions. A risk service can recommend a lower exposure limit, but its API should not become an unrestricted withdrawal authority.

How we approach protocol design

Our design sequence is assets → actors → states → permissions → incentives → settlement → emergency paths. We work through it using complete user journeys and numerical examples, then turn the resulting rules into implementation and acceptance criteria.

Define assets, claims and the people expected to act

We distinguish the assets the protocol holds from the rights it issues. Collateral, vault shares, debt, pending withdrawals and reward tokens need separate accounting. A vault share and the underlying inventory cannot both be counted as independently available backing for the same obligations.

Next we map actors to economic responsibilities: borrowers repay, lenders supply capital, liquidators acquire positions, solvers deliver quoted assets, oracle providers report observations and governance changes approved parameters. For each dependency, we identify what the actor needs to perform that role. A liquidation mechanism is incomplete if the proposed buyer lacks capital, transfer eligibility or a viable exit from the seized asset.

Specify states and the authority to change them

Each operation gets a lifecycle with explicit intermediate states. A withdrawal may be requested, locked, claimable and paid. An oracle observation may be received, disputed and finalised. A matched trade may still be unable to settle. These states determine whether assets remain spendable and which obligations reserve liquidity.

The permission matrix states who may trigger each transition and what evidence the contract checks. We separate routine execution, parameter administration, emergency suspension and recovery. Permissionless finalisation can be appropriate once a deadline and all required conditions are satisfied; changing those conditions belongs to a different authority.

Test whether incentives still work under stress

We model who pays for execution and why someone would supply liquidity or close a distressed position. Liquidation compensation must account for gas, slippage, capital commitment and the route back to cash. Keeper incentives need to remain meaningful for small positions and during congestion, not only at the launch assumptions.

Reward mechanisms also need an abuse model. We examine whether self-trading, repeated deposits, fragmented positions or related counterparties can collect rewards without providing the intended service. Where the mechanism cannot distinguish useful activity from a cheap imitation, we change the reward rule or bound the subsidy before adding it to contracts.

The client receives parameter ranges with their assumptions and sensitivity. For example, extending collateral redemption time can increase backstop capital costs and reduce sustainable borrowing capacity. A parameter chosen under one liquidity assumption must not silently remain valid after that assumption changes.

Follow settlement through to the final obligation

We identify the point at which each party has actually delivered. Within a supported atomic transaction, required asset movements can succeed together or revert together. External venue fills, bank receipts and asynchronous redemptions require pending states, reservations and recovery procedures.

The settlement specification covers amounts, fees, rounding, duplicate attempts and partial completion. It also defines what a failed operation leaves behind. A withdrawal request must not leave both freely transferable shares and a claim against their full redemption value. A solver acknowledgement must not create a funded user balance before the promised asset arrives.

Design emergency paths before the first release

For every material failure, we decide which operations stop, which can continue and who can restore service. New borrowing may stop on stale valuation while repayment remains available. Withdrawals, liquidations and claims need their own policies because their safety depends on the incident and the records still considered reliable.

We implement one complete asset lifecycle first, including its failure paths. A lending scope might begin with deposit, borrow, interest accrual, repayment, liquidation and loss recognition for one collateral type. Additional markets inherit only the parts of that model that still apply to their liquidity and oracle assumptions.

Decisions that matter

What if the oracle is stale, disputed or manipulated?

An oracle interface needs more than a price. We specify units, observation time, permitted reporters, publication delays and the policy for accepting a new value. A recently delivered report can still describe old conditions. Multiple feeds can also share one underlying source, so counting endpoints does not establish independent evidence.

Failure behaviour depends on the action. Keeping the last price indefinitely may allow new borrowing against overstated collateral; setting the value to zero can trigger unjustified liquidations. We define freshness limits and guarded states separately for new exposure, position maintenance and forced settlement. A fallback source must meet a documented quality threshold before it can take over.

For prediction markets, the oracle defines the event outcome rather than simply supplying a tradable price. Observation windows, cancellation rules, dispute periods and invalid outcomes belong in the market specification. A later metadata edit cannot silently rewrite the payout terms of positions already held.

Is the problem insufficient liquidity or an actual loss?

A protocol can own enough recoverable value to cover claims while lacking immediately available settlement assets. That requires a liquidity policy: queues, pro rata processing, redemption windows or committed backstop funding. The interface must distinguish total asset value from what a user can withdraw now.

Insolvency requires a different response. If recoverable assets fall below obligations, the specification must identify the deficit and the agreed loss allocation. We define the affected market or vault, any reserve or subordinated layer, and the treatment of pending claims. Continuing to redeem at an obsolete share price can shift the deficit onto later users.

For an illustrative vault with 1,000 units of claims, 100 units of cash and assets expected to return 900, the immediate constraint is liquidity. If those assets can now return only 700, there is also a 200-unit shortfall before recovery costs. Queue management alone cannot resolve that loss, and a documented loss waterfall cannot produce immediate cash from assets still awaiting redemption.

Can liquidations complete if all need the same liquidity?

We test liquidation against executable depth, eligible counterparties and shared capital limits. A quoted collateral value is not a commitment to buy. A backstop funded for a small portion of exposure cannot absorb the entire market during a correlated event.

The model includes simultaneous liquidations, a depleted backstop, adverse price movement during settlement and delayed recovery proceeds. It specifies where unresolved collateral and debt remain when no immediate sale is possible. Liquidation thresholds and admission caps then reflect that capacity instead of assuming a bot will always appear at the configured bonus.

Which strategies extract value without breaking the code?

An attacker may use ordinary calls in an adversarial sequence. We examine flash-funded price changes, donation effects on share pricing, repeated rounding, reward farming and deposits or withdrawals around valuation cutoffs. For each strategy, the question is whether the resulting claim exceeds the value contributed or consumes another participant's reserved assets.

Settlement ordering matters as well. A route can satisfy signature checks while delivering an economically unacceptable price. Minimum outputs, deadlines and bounded fees therefore remain part of the authorised operation. Private routing can reduce some information exposure, but it does not replace those execution constraints.

How much authority does governance need?

We list privileged actions individually: changing an oracle, raising an exposure cap, upgrading a module, transferring reserves and pausing a market. Each gets an authorised role, an effective time and a rule for existing positions. An operator allowed to adjust a fee should not automatically gain authority to replace settlement logic.

Timelocks provide a review window only when the change and its consequences are observable. We define which changes require a delay and how users can respond during it. Emergency permissions stay narrower than ordinary governance, with separate recovery authority and an auditable reason for each intervention.

What can a circuit breaker actually prevent?

Checks that must reject an unsafe action before it completes belong in the execution path. These include the applicable accounting bounds, price validity checks, reentrancy controls and outflow limits. An external detector may first observe harmful activity after execution, especially when it cannot inspect the submission route.

The breaker therefore has a precise scope and success condition. Submission is pending until the intended pause is confirmed in canonical chain state. Recovery requires verification of the cause, accounting and any corrective change. Automatically unpausing when an alert disappears could reopen the same failure path.

The failure matrix becomes part of implementation and operator training:

Selected work

GridLockNode, CreditMesh and ZeroS illustrate emergency authority, lending against slow collateral and prediction-market settlement. These examples describe the architecture and engineering scope documented in the project materials.

GridLockNode: automated containment, restricted authority

GridLockNode addresses a conflict in automated defence: a service needs enough authority to interrupt harmful activity, but a false positive or compromised detector must not grant it control of protocol assets. Fast detection is useful only if the response has a defined scope and can be verified on-chain.

We separated detection, incident authorisation and signing. The circuit breaker restricts automated credentials to registered pause scopes; they cannot withdraw assets, upgrade contracts, expand their roles or unpause the protocol. Simulations reference a concrete block, and the response record retains the evidence and policy behind the decision.

The scope includes chain-specific observation, bounded simulation workers, a risk engine, isolated signing, scoped breaker contracts and canonical pause verification. Recovery follows a separate delayed authority. The architecture distinguishes response-submission objectives from actual containment, because an external service cannot guarantee it will execute before every attack. Read the GridLockNode case study.

CreditMesh: lending limits set by the route to cash

CreditMesh addresses lending against tokenized funds whose shares may require notice, redemption windows and eligible recipients. A published asset value does not establish that a liquidator can receive the shares or sell them immediately. Several nominally separate markets may also depend on the same custodian or administrator.

Our architecture gives each collateral asset a liquidity profile and uses funded, eligible backstop sleeves to bridge the wait for redemption. A sleeve's payment reduces market debt, while a tracked recovery lot preserves the relationship between seized shares and later proceeds. Settlement caps the sleeve's compensation and returns qualifying surplus to the borrower after remaining debt is addressed.

The scope includes isolated lending markets, lender vaults, attested valuation, staleness rules, redemption adapters and exposure caps for shared institutional dependencies. Exhausted backstop capacity leads to an explicit recovery lot rather than an assumption of unlimited liquidity. Loss accounting remains attached to the affected market and the vaults exposed to it. Read the CreditMesh case study.

ZeroS: settled ownership and precisely defined hedges

ZeroS combines confidential ownership with prediction-market execution. Its problem is both financial and semantic: private claims must remain backed by the exact assets in custody, and an opposing market position must have matching payout rules before it can count as a complete hedge.

We separated execution intent from settled ownership and defined a resolution registry covering conditions, collateral, observation windows and payout rules. Exact complements are distinguished from related markets that retain basis risk. Solver settlement binds both parties to the same trade terms and verifies the corresponding asset transitions together.

The architecture includes custody contracts, a private ownership ledger, routing, solver and adapter settlement, resolution metadata and strategy-vault accounting. Redemption locks spendable share claims, reserves claimable collateral outside strategy capital and applies pro rata processing when the defined epoch lacks sufficient liquidity. A deadline can stop new exposure and trigger an unwind attempt, but cannot guarantee that liquidity exists to complete it. Read the ZeroS case study.

What the client receives

We define delivery against the supported assets and the protocol's financial invariants. Testing covers sequences of actions and changes in external conditions, including states in which the product cannot honour an immediate exit.

• Architecture and economic specifications covering assets, liabilities, actor responsibilities, parameter assumptions, state machines, permissions and loss allocation.
• Contracts for the agreed markets, vaults, settlement paths, oracle adapters and governance or emergency controls, with explicit upgrade and migration boundaries.
• Numerical models and simulations for liquidity demand, correlated shocks, manipulation strategies and incentive sensitivity, with inputs and limitations documented.
• Unit, integration and stateful invariant tests that check conservation, rounding, duplicate execution, authority boundaries and recovery; fork-based scenarios where they materially test external integrations.
• Infrastructure for indexing, oracle delivery, keepers, execution workers and reconciliation, with bounded retries and durable operation records.
• Monitoring for backing discrepancies, oracle age, liquidity utilisation, liquidation backlog, privileged changes and incident state, linked to operator procedures.
• A deployment plan with reviewed versions and parameters, role assignments, agreed security review results, initial exposure limits and criteria for expanding supported markets.

Before enabling material exposure, we rehearse stale data, unavailable liquidity, loss recognition and emergency recovery with the operating team. The launch decision uses those results alongside contract review. Operators need to know what the protocol can still execute under stress, what remains owed and which authority can take the next step.