Skip to content

Backend Or Oracle Engineer Guide

What To Understand First

  1. Economic Observation Flow
  2. Economic State Lifecycle
  3. Receipt Posting
  4. Handling Stale Oracle Data
  5. Claimability Rules

What You Are Allowed To Do

Backend/oracle engineers produce evidence for risk observations, source ids, receipt groups, reserve proofs, and monitoring. They may operate transaction paths only if assigned through governance.

What You Must Never Do

  • Reuse economic source ids or source groups.
  • Submit unfinalized observations as finalized.
  • Hide same-epoch conflicts.
  • Backfill receipt data without replay evidence.
  • Widen freshness windows to mask outages.

Responsibilities

Maintain finalized, ordered, replay-safe feeds. Ensure source uniqueness, freshness, reserve proof timestamps, and receipt classification evidence are available to operations before transactions are sent.

Failure Modes To Recognize

Stale observations, same-epoch conflict, duplicate source id, missing source group, inconsistent validator balance, slashing/ejection risk, and receipt amount mismatch.

Escalation

Escalate to operations and protocol engineering when feed health can affect claimability, deposit readiness, reserve coverage, or settlement.

Role Operating Guide

What This Person Must Understand First

The Backend or oracle engineer must understand risk observations, receipt sources, safe epochs, stale-data windows, reproducibility requirements. The four questions must stay separate: Upgrade governance asks which code is official, Deposit permissioning asks who may deposit, Custody/readiness asks whether the deposit route is safe, and Economic/claim safety asks whether funds can later leave safely.

Allowed To Do

This role may prepare and submit approved data feeds when the relevant runbook, permission matrix, and reviewer approval support the action.

Must Never Do

This role must never invent or backfill source evidence without audit trail.

Pages To Read In Order

  1. System Map
  2. Permissioned vs Permissionless Deposits
  3. Permission Matrix
  4. Source Manifest
  5. The runbook for the exact action being performed.

Routine Responsibilities

Keep evidence current, record decisions, reconcile action tickets to onchain events, and raise drift quickly. Do not rely on memory when a source manifest, event log, or contract read can answer the question.

Incident Responsibilities

Stop routine automation for the affected layer, preserve evidence, notify the correct owner, and avoid broad remediation until the failing layer is identified.

Escalation Triggers

Escalate on unknown governance actions, mismatched implementation metadata, unexpected allowlist-admin transfer, stale oracle data, slashing/exit anomalies, failed custody readiness, or any claim that cannot be tied to current source and onchain evidence.