6 min readJuly 9, 2026

Building an Institutional Risk Framework from Onchain Data

a risk or allocator client

Governance, risk, and market structureDigital-asset infrastructure

Context

A risk or allocator client needed a way to govern onchain exposures with the discipline expected in an institutional risk function. Existing dashboards showed balances, positions, and market data, but they did not provide a reliable chain from source state to an exposure view, a risk category, and an accountable decision. Traditional reports, meanwhile, were not designed for composable positions whose value and dependencies can change as protocols update or markets move.

The engagement drew inspiration from Basel III risk-data and capital-management ideas: clear definitions, aggregation, lineage, concentration awareness, liquidity treatment, and evidence about data quality. It did not attempt to import a banking rulebook into a protocol or claim regulatory compliance. The useful transfer was the discipline of asking whether risk information was complete, reconcilable, timely, and suitable for governance.

Challenge

Onchain exposure rarely sits in one account or one instrument. A position may be represented by a receipt token, depend on collateral elsewhere, contain a claim on a vault, or inherit risk from an oracle, bridge, issuer, or liquidity venue. Looking only at wallet balances can hide the economic exposure underneath. Aggregating everything into a single number can hide concentration and make different failure modes appear interchangeable.

Data quality was part of the risk problem. Protocol state could be fresh while a price input was stale. An indexer could miss events and still return plausible totals. Asset identifiers could be consistent at the token level while representing different economic claims. Historical reporting could drift from the current interpretation of a position after a protocol upgrade.

The client needed a framework that preserved enough detail for investigation while producing a view that could support limits, escalation, and review. It also needed monitoring that responded to state changes rather than a periodic spreadsheet assembled after conditions had moved.

Approach

We first defined an exposure taxonomy around economic risk, not just protocol labels. Positions were decomposed into underlying assets, claims, obligations, dependencies, and control points. The model recorded both direct exposure and look-through exposure so that a wrapper or vault did not obscure what ultimately drove value or loss.

Lineage was designed into the model. Every aggregated figure needed a path back to its source state, transformation, valuation input, and observation time. Reconciliation checks compared independently derived views where practical and treated disagreement as a data-quality event rather than automatically selecting one source. Completeness indicators made missing or delayed inputs visible to downstream users.

The framework then organized risk around decisions. Concentration views showed where multiple positions shared an issuer, venue, oracle, or liquidity dependency. Liquidity treatment distinguished quoted value from the ability to exit or redeem under stress. Aggregation preserved material dimensions instead of flattening all exposure into a portfolio total. Data-quality status accompanied the exposure so a clean-looking number could not be mistaken for reliable evidence when its inputs were degraded.

Monitoring connected these definitions to live state. The system observed exposure changes, dependency health, pricing freshness, reconciliation breaks, and material changes in concentration or liquidity conditions. Alerts were intended to initiate a defined review process, with context about the source and affected positions, rather than produce a stream of isolated threshold notifications.

From framework to operating practice

The work distinguished measurement from governance. A model can identify concentration or deteriorating liquidity, but an organization still needs ownership, escalation paths, and a record of how exceptions are handled. We therefore described how monitoring evidence should reach the relevant decision process and how a reviewer could reproduce the underlying view.

This was also where the limits of the analogy mattered. Basel-inspired discipline can improve definitions and evidence, but an onchain system has different legal structures, loss mechanics, market hours, and technology dependencies from a bank. The framework remained an onchain risk tool informed by established practice, not a representation that the client or any protocol met a banking regulatory standard.

Outcome

The framework connects raw onchain state to look-through exposures, concentration, liquidity, and data quality through an operational monitoring process. Risk information carries its lineage and data-quality status from source to aggregation. Live changes can be traced to the positions and dependencies they affect.

The architecture eliminates hidden transformations between source data and decision material. Economic exposure is distinguished from technical exposure. Data quality is treated as a risk attribute, not a back-office concern. The framework enables institutional discipline without claiming Basel compliance.

What this demonstrates

Matariki combines onchain data engineering with risk-model design. The method is to preserve lineage and protocol detail while building an aggregation layer that serves real decisions. It is applicable to allocators, treasury teams, risk functions, and protocols that need more than a balance dashboard but cannot rely on traditional reporting models unchanged.

Confidentiality

This account excludes the client identity, holdings, counterparties, limits, alert configuration, governance processes, and monitoring parameters. It describes a generalized framework and delivery method.

Related

Related work

Work with us

Apply this thinking to a live system.

Speak with Us