Skip to content

Data Sanctity: The Invariant of State

Backpac enforces a singular timeline of Truth.

The common "Read-After-Write" fallacy—where a transaction is committed but cannot be verified due to node lag—is an unacceptable break in continuity for institutional operations. Backpac eliminates this fragmentation through State Pinning.

1. State Pinning: Deterministic Continuity

When an institutional intent enters the Backpac Engine, the system guarantees a consistent signal path to ensure you can always read what you have written.

  • The Mechanism: Backpac pins your active session to the specific provider that processed your write operation.
  • The Result: Subsequent read requests (e.g., querying for a transaction hash or account state) are strictly routed to the same authoritative source, collapsing the consistency window to zero.

2. The Identity of Intent

To enforce pinning, the Engine requires a persistent identifier for the signal path.

Explicit Requirement (x-backpac-sender)

For raw execution (e.g., eth_sendRawTransaction), the Identity of Intent must be provided via the x-backpac-sender header. This ensures the Engine can map the intent to the correct state timeline without the throughput overhead of raw payload inspection.

http
POST / HTTP/1.1
Host: ethereum-mainnet.backpac.xyz
X-Backpac-Sender: 0x123...abc
Protocol: JSON-RPC

IMPORTANT

Identity is Law: Without an explicit sender header, high-fidelity state pinning cannot be guaranteed for raw transaction broadcasts.

Automatic Resolvers

For high-level methods, the Engine automatically resolves identity from the payload if the header is absent:

  • eth_sendTransaction
  • eth_call
  • eth_estimateGas

Institutional Guarantees

  • Infinite Consistency: Eliminates "Transaction Not Found" errors immediately following a broadcast.
  • Zero-Logic Integration: Removes the need for complex, client-side retry loops or state-tracking middleware.

Activation

Configure State Pinning as the primary algorithm within your Reliability Pool settings. This protocol is currently optimized for EVM-standard settlement environments (Ethereum, Polygon, Base).


Data Sanctity: Because a ledger that is not consistent is not a ledger.

Settlement Certainty Layer