Ethereum & Solana Mirrors

External access to canonical evidence

The mirror system builds authenticated batch archives, publishes them to Ethereum or Solana and retrieves them through independently configured chain sources. An archive preserves canonical data and its signed-header authorization so another system can verify a receipt or state fact without contacting the Paxeer X gateway.

Mirror publication distributes evidence. Paxeer custody and settlement remain governed by their own checkpoint authority and contracts. An external chain's publication confirmation alone does not authorize a Paxeer withdrawal.

Publisher and verifier roles

Trust configuration

Configure the LayerX network identity, sequencer identifier, Ed25519 public key and authorized first/last batch range independently of archive payloads. A mirror archive cannot authorize its own signing key or extend that range.

Retain target-chain identity and canonical position with each observation. On Ethereum this includes the observed block and reference head; on Solana it includes the rooted slot and block hash.

Publish an archive

layerx-mirror-publisher /etc/layerx/mirror-publisher.json

1. Connect to the native node using the configured socket, network, protocol and resource bounds.
2. Authenticate the signed batch header and fetch its complete availability material.
3. Build and validate the archive, preserving its exact canonical bytes and content commitment.
4. Persist publication intent, obtain target-chain signatures and broadcast.
5. Observe configured chain confirmation or rooting, retrieve the published archive and verify the bytes.
6. Advance the durable publication cursor only through the recorded publication workflow.

Publisher configuration includes the state directory, first batch, polling interval, status listener, checkpoint freshness budget and target-chain transaction bounds. The Ethereum target is configured explicitly; the Solana section is optional and validated when present.

Recover publication safely

The publication journal distinguishes prepared, signed, pending, finalized and retrieved-verified states, alongside pre-broadcast failure, unknown broadcast, permanent refusal, reorganization and expired broadcast. When broadcast status is unknown, resolve chain history before issuing a replacement nonce or blockhash.

Readiness includes checkpoint freshness against the configured batch budget. A healthy process and a completed historical publication do not by themselves establish that every target is current.

Read policies

A candidate identifies the configured source index and exact archive commitment. Source divergence, insufficient agreement, missing data, RPC divergence and rate limits remain distinct outcomes.

Verify a receipt from a mirror

Prepare a verifier configuration with your independent network and source pins. Supply a JSON request on standard input. Replace these labeled placeholders with exact hexadecimal receipt bytes and the 32-byte archive commitment:

{
  "batch_number": "12",
  "evidence": {
    "kind": "receipt",
    "canonical_hex": "REPLACE_WITH_CANONICAL_RECEIPT_HEX"
  },
  "policy": {
    "kind": "exact",
    "candidate": {
      "source": 0,
      "commitment_hex": "REPLACE_WITH_32_BYTE_ARCHIVE_COMMITMENT_HEX"
    }
  }
}

layerx-mirror-verify /etc/layerx/mirror-verifier.json < receipt-request.json

The verifier checks source commitment, archive structure, signed-header authority and signature, canonical receipt semantics and receipt inclusion. Batch numbers are nonzero canonical decimal strings without leading zeros. Unknown request members are refused.

Verify a state fact

A state request uses evidence.kind: "state", canonical_hex and proof_hex. The proof bytes decode through the canonical Merkle proof codec before the state verifier checks inclusion. Preserve the exact canonical value and proof; display data cannot replace either.

Interpret the result

The verifier prints an ok envelope. Successful verification includes the achieved evidence level, batch number, signed-header digest, evidence digest, source ID, target identity, canonical position, provenance, latest batch, batch lag, failover count and agreeing source count.

BatchIncluded establishes the receipt's authenticated batch inclusion; StateProven establishes the supplied state fact. Freshness is reported separately and can be unknown. Store the observation and trust configuration with the evidence so later readers can distinguish historical validity from current coverage.

Checkpoint authority is explicit

The Rust verifier provides checkpoint_with_native_authority to validate a retained native certificate against independently configured Paxeer checkpoint authority. It refuses legacy archives, mismatched checkpoint identity, invalid native evidence, non-final state and reorganization failures.

The command-line receipt/state report labels checkpointLevel as unavailable. Applications requiring native checkpoint assurance must explicitly invoke the corresponding authority-aware path; they cannot infer it from a receipt inclusion level or external-chain finality.

Archive retention and audit

Keep the archive commitment, canonical archive bytes, trusted sequencer range, target identity, canonical chain position and evidence verification result together. For settlement audits retain native certificates and independently authorized checkpoint policy as well.

Continue with Relay & Archive Nodes for public history endpoints, Receipts & Proofs for portable verification, and Data Availability for authenticated replay bundles.