Context
A lending protocol needed to integrate with several onchain lending venues and make their state available to downstream product and risk systems. Each venue exposed familiar concepts—supplied assets, borrowed assets, collateral, utilization, and liquidation—but encoded those concepts through different programs, accounts, interest models, price sources, and lifecycle events.
The desired result was a common interface. The architectural risk was building an interface that looked consistent by discarding the differences that mattered. A unified balance is useful only if consumers can also understand how fresh it is, how it was derived, and which venue-specific conditions affect its meaning.
Challenge
Venue integrations failed in more ways than a normal API adapter. Onchain state could be internally consistent while an indexer lagged. An account could change meaning after a program upgrade. Interest and exchange-rate calculations could depend on venue state observed at a different slot from the position. A market could pause or enter a protective state without the shared interface having a direct equivalent. Liquidation and bad-debt behavior could differ even where headline collateral ratios looked similar.
Normalization created a second class of risk. If all venues were forced into the lowest common denominator, the interface would hide important state and encourage consumers to compare unlike exposures. If every difference leaked through, each consumer would reimplement venue logic and the integration layer would provide little value.
The system also needed operational answers. It had to know when data was incomplete, reconcile indexed state against authoritative program state, recover from gaps, and prevent stale or partially decoded records from appearing current. Private venue parameters and deployment-specific mappings could not become assumptions embedded throughout the product.
Approach
We defined a canonical model around stable economic and operational concepts. Common fields represented assets, positions, obligations, collateral status, observation context, and source quality. Venue-specific extensions preserved information that could not be expressed safely in the common model. This made the shared interface useful without claiming that all venues had identical risk.
Each adapter owned the translation from native accounts and events into that model. The adapter documented how values were derived, which program versions were supported, which dependencies were required, and which states could not be represented. Decoding and calculation logic remained close to the venue boundary rather than spreading through consumers.
The indexing pipeline treated slot and commitment context as data. Records carried their observation point and dependency status. Backfill and live ingestion converged through the same transformation path so historical and current views did not drift. Idempotent processing allowed retries without duplicating state transitions. Version-aware decoding created an explicit response to program change instead of silently applying an old layout.
Reconciliation operated at several levels. Counts and account sets checked coverage. Position totals checked aggregation. Selected records were recomputed from authoritative state to test transformations. Inconsistencies produced a quality state and an investigation path rather than being overwritten by whichever source arrived last.
Failure and monitoring model
Consumers needed to distinguish no position from no reliable data. The interface therefore represented unavailable, delayed, partially supported, and inconsistent states explicitly. Product systems could choose their behavior based on quality, while risk systems could exclude or escalate uncertain exposure instead of treating it as zero.
Operational monitoring covered ingestion continuity, processing delay, decoding failures, reconciliation breaks, dependency freshness, and unexpected venue state. Runbooks connected each signal to the adapter and source context required for diagnosis. Recovery procedures were designed to replay data deterministically and verify convergence before a degraded integration returned to normal service.
Venue differences remained visible in documentation and the model. Liquidation behavior, supported collateral, price dependencies, and protective states were not collapsed into a single risk score. The integration created a common access layer, not a false claim of common economics.
Outcome
The architecture normalizes shared concepts across venues while retaining venue-specific context and quality signals. Downstream systems consume a consistent interface, trace derived values to their source, and respond deliberately when data is stale, incomplete, or degraded.
Venue logic is not duplicated. Product and risk decisions have a consistent source. Reconciliation and monitoring are part of the integration contract, so data usability is evaluated continuously, not assumed after initial success.
What this demonstrates
Matariki treats protocol integration and data infrastructure as one problem. A useful abstraction must reduce repeated work while preserving the distinctions that affect risk and operations. This method applies to lending, vault, liquidity, and portfolio systems that depend on several evolving onchain venues.
Confidentiality
This account excludes the protocol identity, venue-specific private parameters, account mappings, deployment details, operational thresholds, and monitoring configuration. It describes the normalized model and reliability method.