Backend Or Oracle Engineer Guide¶
What To Understand First¶
- Economic Observation Flow
- Economic State Lifecycle
- Receipt Posting
- Handling Stale Oracle Data
- 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¶
- System Map
- Permissioned vs Permissionless Deposits
- Permission Matrix
- Source Manifest
- 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.