Context
A DeFi protocol needed a vault designed and taken through a separate validation pass before it held user value. The vault would accept assets, issue a claim, apply a strategy or allocation process, and support withdrawal under defined conditions. Each piece was familiar in isolation. The system risk came from the relationships between product promises, accounting, external integrations, authority, and operational response.
The engagement separated design work from a later validation pass. Matariki helped define the solution, then returned to the resulting system against its intended behavior and failure modes rather than treating the design rationale as evidence. This distinction mattered because assumptions that feel obvious during architecture work still need to be challenged against the assembled system.
Challenge
Vault correctness has several layers. Product behavior defines what depositors believe they own and when they can exit. Economic assumptions define valuation, liquidity, losses, fees, and how claims remain fair between users. Program architecture defines state transitions and integration boundaries. Authority design determines who can change strategy, restrict activity, recover from failure, or upgrade code.
A code review can find implementation defects without establishing that these layers agree. A mathematically correct share calculation can still sit inside a product with an impossible withdrawal promise. A safe program can call an external venue whose degraded state the vault does not handle. A well-designed strategy can be undermined by authority that can alter critical behavior without sufficient control.
The protocol needed both a buildable architecture and evidence that the complete solution matched its stated behavior. Exact financial settings and private review findings were not suitable for public disclosure, but the validation method could be described.
Approach
We began with a behavioral specification. Deposit, allocation, valuation, withdrawal, rebalance, pause, recovery, and closure were described as state transitions with preconditions and observable outcomes. The specification distinguished normal operation from exceptional paths and identified where asynchronous activity or external dependencies changed what the vault could promise.
Economic assumptions were documented separately from code. The model covered how claims were issued and redeemed, how gains and losses were attributed, how liquidity affected withdrawal, and how stale or disputed valuation inputs were handled. Rather than accepting a single expected scenario, the review considered ordering effects and stressed conditions that could transfer value unfairly between participants.
The program architecture assigned responsibilities to components and accounts. External integrations had explicit boundaries, supported states, and failure behavior. Authority was decomposed by action so routine operations, strategy changes, emergency restrictions, and upgrades did not default to one undifferentiated administrator. Monitoring requirements followed the state machine and the economic assumptions.
The separate validation pass rebuilt the reasoning from the specification outward. It traced user claims to program transitions, checked critical invariants, challenged dependency assumptions, and examined whether recovery paths preserved accounting. Tests covered expected flows, invalid transitions, ordering, degraded integrations, stale inputs, and partial completion. Findings were categorized by the layer they affected so a product or operating gap was not mislabeled as only a code issue.
Beyond code review
Solution validation asked questions that source inspection alone could not answer. Did the documentation describe the implemented withdrawal behavior? Could operators distinguish a temporary dependency failure from a vault accounting problem? Did authority match the responsibilities approved by the product owner? Would monitoring detect an invariant break before normal activity continued?
The process also required evidence for closure. A changed implementation was retested against the original behavior and adjacent failure paths. Updated operating procedures were reviewed where a control depended on human action. Remaining limitations were documented as constraints on the system rather than hidden behind a successful test run.
Outcome
The architecture connects product behavior, economic assumptions, program boundaries, authority, monitoring, and recovery explicitly. A separate validation pass tests whether the solution matches the design and whether failure handling preserves intended user claims.
The team has a shared model of the complete system. Evidence is tied to important invariants. Limitations are documented for operation. This method surfaces issues that design confidence or code review alone might miss.
What this demonstrates
Matariki can design a protocol and still separate validation from the act of producing the design. For vaults and other value-holding systems, the work joins product specification, economic reasoning, program architecture, authority, testing, and operational readiness. Passing a code review is one input, not the definition of a validated system.
Confidentiality
This account excludes the protocol identity, financial parameters, strategy details, authority configuration, private findings, remediation records, and deployment information. It describes the generalized design and validation method.