Skip to Content
⚠️ Alert: Sylan is under active development—only trust contract/wallet addresses announced on our official channels; we will never DM you, ask for funds, or run surprise airdrops/presales.
NodeConsensus Flow

Consensus Flow

The node follows this deterministic loop for each request.

Snapshot (EIP‑712)

The provider signs a typed Snapshot with fields:

apiId: bytes32
seqNo: uint256
providerTs: uint64  // unix ms when the provider produced this snapshot
ttl: uint64         // permissible lifetime in ms (0 = no TTL)
contentHash: bytes32 // keccak256 of canonical off‑chain content

The node verifies:

  • Signature recovers to the provider signer for the apiId.
  • providerTs is within maxSkewMs of the block time.
  • If ttl > 0, providerTs + ttl has not passed yet, and also respects any maxTtlMs cap.
  • (If enabled by a given API) seqNo monotonicity is enforced by APIConsensus on finalization.

Pointer & IPFS

Nodes may pin a compact pointer JSON (e.g., including requestId, contentHash, and providerTs) to IPFS.

  • If PINATA_JWT is set, Pinata is used; otherwise the node tries the native IPFS HTTP API (IPFS_API_URL).
  • The returned ipfs://… URI is submitted as pointerURI for auditability.

Backoff, jitter, and confirmations

  • Exponential backoff with jitter protects providers during spikes.
  • Configurable CONFIRMATIONS helps avoid reorg hazards on reads.
  • If WS_RPC_URL is absent, the node polls from POLL_FROM_BLOCK.
Last updated on
SetupOperations