What breaks when integrating Band Protocol without custom scripts
Band Protocol delivers data via a pull model: the contract itself requests the value at call time and pays for its delivery. An off-the-shelf integration looks simple — take a published price feed and read it from the settlement logic.
The problem is that the feed describes an "average market price," while the contract needs a specific pair, a specific source, and a rule by which the value can be accepted at all.
The first thing that breaks is quote divergence. If there is a single source and the value is collected without cross-venue aggregation, the difference from the actual trade accumulates and becomes noticeable precisely during volatility.
The contract executes a liquidation or swap at a price that no longer exists on the market, and the calculation starts working against the protocol.
The second failure is stale data in the smart contract. The feed updates on its own schedule, not when the market moves; between two deliveries the value lives in the contract although the real price has long moved.
Without freshness checks and a deviation threshold, the settlement logic takes an old timestamp as current and confirms an operation that should not have been confirmed.
The third is the oracle bottleneck as a single point of failure: when the source is unavailable, it is not just one call that stops, but the entire settlement cycle, and no correct retroactive record is made.
Custom source scripts close all three failures: they define the list of venues, aggregation rules, and the freshness condition under which the value can enter the contract at all. Below we break down how this is addressed.
What changes after implementation: divergences, delays, downtime
The first effect is visible in the share of divergences. Before integration, the value in the contract and the value at the source did not always match: divergence accumulated between manual updates and surfaced only during incident review.
After Band Protocol integration, both ends are compared automatically, and divergences remain isolated — usually on the source side, not the delivery side.
The second is reaction time to data changes. Previously it equaled the pause until the next scheduled update, i.e., measured in hours and depended on the on-call engineer.
Now the update is initiated by the very fact of change, the delay fits within one delivery cycle, and update frequency stops being a trade-off between freshness and node load.
The third is the class of failures that ceases to exist.
The scenario "source unavailable, contract settles by the last known value" goes away: in the pull model, data is requested at settlement time, and if there is no fresh response, the operation does not go through instead of executing on stale numbers.
The fourth is observability of the data flow. Each update leaves a record with timestamp, source, and signature, and a deviation from the previous value above a specified threshold raises an alert. The share of manual reconciliations drops to selective checks per procedure instead of daily ones.
Band Protocol: pull model instead of scheduled updates
In Band Protocol, value delivery is built around the pull data model: the contract requests the price at call time and verifies the validators' signature itself.
With scheduled updates, the value is written to storage in advance — reading is cheaper, but freshness is limited by the update period, and the initiator pays for the write regardless of whether there was demand for that value.
The choice of mode is a trade-off between read latency and verification cost inside the transaction.
If settlement relies on a single exchange value, an anomaly on the venue goes straight into trade execution: aggregating sources with a median and outlier trimming smooths this out, while a backup data source covers the case when the primary aggregator is unavailable or returns a stale value.
| Option | When it fits | Limitations |
|---|---|---|
| Pull model on demand | Need a price at the moment of trade execution | Signature verification inside the call increases gas cost |
| Scheduled updates | Constant reads: reports, liquidity pools | Between updates the value goes stale, writes happen idle |
| Own source | Narrow asset set, closed markets | Single point of failure, direct dependence on one venue |
| Hybrid: aggregation and backup | Large volumes, lending protocols | Harder maintenance: must monitor divergence between sources |
We assemble such a scheme for a specific contract: in some cases a pull model from one aggregator is enough, in others a backup and a custom value-bounds check script are needed.
Implementation stages: source audit, scheme, configuration, verification
The order of work is fixed: unverified sources make the update scheme meaningless, and without a scheme, script configuration turns into guesswork.
Each stage ends with an artifact — a list, a scheme, a configuration — so at acceptance it is clear what exactly was checked and on what data.
- Data source audit. We collect the feeds used by contracts and compare them against the registry: who publishes the value, at what frequency, and whether there is a backup channel if the primary fails.
- Data update scheme design. We define the pull model: who initiates the oracle request, at what value deviation threshold, at what interval, and what happens if the update does not arrive on time.
- Oracle script configuration. We write aggregation scripts for Band Protocol: averaging rules, outlier trimming, ticker mapping. We run them on an isolated environment using historical values.
- Acceptance checks. We reproduce scenarios of source divergence, publication delay, and complete failure of one channel. We record system behavior and the boundaries beyond which the transaction does not go through.
- Handover of maintenance procedures. We provide documentation on thresholds, alert order, and on-call actions during deviation, plus instructions for connecting new sources.
Handover artifacts: configurations, schemes, and procedures
Besides the integration code, the client retains a set with which the solution can be maintained and developed in-house: settings, schemes, and procedures describe where data comes from and who is authorized to change it.
The set is stored in the same repository as the contracts — the edit history of the configuration can be restored just like the code history.
- Oracle configuration — custom script settings files: the list of sources for each data set, value deviation threshold, update period, and addresses of contracts to which Band Protocol is bound.
- Data flow scheme — the full route: source → oracle script → write to contract → consumers, with marked failure points and backup sources.
- Access policies — a matrix of roles and keys: who signs update transactions, what limits apply, and where a second signature is required.
- Source update procedure — the order for adding and replacing a source: who approves, in which environment it is tested, and what rollback window is given.
- Monitoring documentation — metrics (update delay, share of successful writes, divergence between sources), configured alerts, and trigger thresholds.
- Incident procedure — actions for unreliable data: switching to backup and rolling back the latest writes.
- Configuration change log — a record of edits with author, reason, and verification result.
This set is sufficient for the client's team to edit sources and thresholds without our support.
Case: data divergences and reaction time before and after
The client's settlement circuit — a service with instant execution of operations — relied on a self-written rate collector: several sources, its own averaging logic, and scheduled value writes to the network.
The scheme held while there were few assets, but each new connection added failure points and ever more manual reconciliations.
Before migration
Divergences between the settlement value and market quotes surfaced several times a day — usually during sharp moves, when the timer-written value lagged the market.
Engineers compared exports manually and investigated disputed operations using logs, and recovery after one source went down took hours: until you were sure the collector was again returning a correct value, settlement could not be stopped.
After migration
The data channel was migrated to Band Protocol: aggregation logic was moved into custom oracle scripts, and scheduled writes were replaced with an on-demand request model — settlement takes a fresh value at the moment of operation, not the one updated by a timer.
Several sources were kept, but the allowable deviation corridor was set explicitly, and an outlier beyond it no longer enters settlement.
Divergences on disputed operations decreased by roughly five times, and the share of trades with manual reconciliation fell from single-digit percentages to tenths of a percent.
Recovery after a source failure fits within minutes: the channel switches to a backup set, settlement continues, and the engineer investigates the cause without stopping the service. Rollback to the previous source set is one configuration edit, without rebuilding the logic.
How the pull model differs from periodic updates
The difference is who initiates the update. In periodic mode, the oracle itself writes the value to the contract on a schedule — the write happens even when no one read it during the interval, and by the time of a trade the data has gone stale.
In the pull model, the value is requested at the moment of access: only the one who needs it pays, and data freshness is strictly tied to the call time.
| Scheme | When it fits | Limitations |
|---|---|---|
| Periodic writes | many readers per update, dashboards and analytics | we pay for updates without readers, freshness limited by interval |
| On-demand access | rare but price-sensitive operations, lending protocols | request and signature verification in every transaction, more expensive per call |
| Hybrid | hot pairs and rare assets in one protocol | a common abstraction layer over two sources is needed |
The choice is dictated by read frequency and the cost of delay. If a stale value leads to liquidation at an incorrect price or to arbitrage on divergence, the update interval stops being a setting and becomes a failure class.
Integration with Band Protocol in such a scenario is built around on-demand reads with response signature verification.
We perform migration from an existing oracle in stages: parallel launch of the new source alongside the old one, reconciliation of divergences on historical data, switching readers one by one, and only then decommissioning the old feed. Rollback at any step is returning the source address in the configuration, without state migration.
Technical concerns: source failure, limits, signing keys
In Band Protocol integrations, the same questions come up during contractor selection: what happens to the contract if the data source goes silent, whether we hit request limits, who has access to signing keys, and what the recovery plan after a failure looks like. Below are short answers to each.
What happens if an external data source stops responding?
In the pull model, the value is requested at call time, so the failure is handled by the consumer contract: it checks the timestamp and deviation threshold.
If the value is older than the allowed window, a backup oracle is connected or the operation is paused until manual confirmation — a stale price does not enter the contract.
Will we hit request limits on the source?
Any data provider has a rate quota. We separate scheduled reads, cache the value between calls, and aggregate several consumers into one request — instead of a stream of small requests, we get predictable load.
As the quota is approached, the contract switches to a backup source instead of failing with an error.
Who has access to signing keys?
The keys used to sign data updates are kept in a hardware module or isolated storage — not in the repository and not in environment variables. Roles are separated: one key publishes values, while the administrative one is needed only for changing the source. Rotation and access issuance procedures are described in the policy.
Let's discuss the task and come back with an estimate and work plan
To make the integration estimate accurate and the oracle work plan feasible, we need inputs on the data source and settlement scheme. Below is a set that is sufficient to come back with architecture, timelines, and scope of work, rather than general wording.
- What we are working with now: in which networks the contracts are deployed and where in the logic external data should appear.
- Data source: where we take values from — our own dashboard, exchange feed, internal service — and how often they change.
- Settlement scheme: which quantities we calculate, what divergence between sources we consider normal, and what to do when the threshold is exceeded.
- Freshness requirements: allowable delay between source update and contract write, behavior when the source is unavailable.
- Signatures and roles: who confirms data, how many confirmations are needed, and how key rotation works.
- Constraints: audit requirements, internal security policies, and access procedures for infrastructure and environments.
- What needs to be delivered: Band Protocol contracts and oracle scripts, deployment scheme, documentation, and knowledge transfer to the team.
This set is enough to propose a concrete integration scheme and a rollout order across environments. Describe the task in your own words — we will come back with an estimate and a work plan broken down by stages and responsibility areas.