Skip to main content

Observability

Observability in a web3‑first system looks different from traditional server‑centric stacks. Much of what matters is intrinsically observable on chain; other aspects are deliberately opaque by design to preserve privacy and safety. This section describes what we measure, how we measure it, and the boundaries we refuse to cross.

What is intrinsically observable​

On‑chain state and events ([Sui architecture][1])

  • Object states: content objects, entitlements, bounties/escrow, reputation, market links; diffs are derived from certified transaction effects and checkpoints.
  • Events: policy updates, entitlement mint/expire, bounty posted/resolved, reputation updated, market resolved; event schemas are versioned.
  • Transaction lifecycle: latency from submission to effects certificate; epoch/checkpoint metadata; consensus path vs fast path characteristics.

Walrus availability ([Walrus design][6], [Walrus ops on Sui][9])

  • Point of Availability (PoA) events and availability certificates for blobs; inconsistency events that mark reads as None.
  • Site object references (dynamic fields mapping paths → blob IDs); catalog manifest IDs.

Client‑side UX telemetry (privacy‑preserving)

  • Page load milestones (TTI, LCP), content fetch timings, path selection (CDN vs Walrus), integrity verification outcomes (hash match/mismatch).
  • Sponsored‑transaction settlement times (intent signature → executed effects), success/failure codes.
  • Identity mode (wallet vs zkLogin) and re‑auth frequency without emitting raw credentials or identifiers.

Oracle receipts

  • Presence and validity of enclave attestations and/or zk proofs attached to resolution receipts; measurement hashes and proof verification outcomes.

What is intentionally opaque​

Encrypted submissions

  • Payload contents, filenames, and MIME types for source→journalist packages are never logged or transmitted in plaintext. Only hashes and optional Walrus blob IDs are public.

Private identity material

  • zkLogin ID tokens, salts, and ephemeral keys are never transmitted beyond what zk proofs require. The chain never sees raw IdP tokens; the IdP never sees on‑chain activity ([zkLogin][3]).

User‑specific reading behavior

  • Which exact stories an individual user read is not reported to any server. Telemetry aggregates at cohort or anonymous levels and never includes on‑chain addresses tied to behavior.

Model inputs inside enclaves

  • Inputs to confidential AI workflows (inside [AWS Nitro Enclaves][10]) remain opaque; only attested measurements and result hashes/receipts are observable.

Metrics and SLIs​

End‑user experience

  • Content retrieval success rate (after fallback) ≥ target; median page load < target; 95th percentile content fetch under fallback < target.
  • Sponsored transaction median settlement time < target; failure rate under quota < target.

On‑chain health

  • Time from submission → effects certificate; percentage of transactions on fast path vs consensus path; event ingestion lag for client indexes.

Walrus delivery

  • CDN hit ratio; fallback rate to Walrus; hash mismatch rate (should be ~0); PoA lag for new uploads.

Oracle validation

  • Share of resolutions with valid receipts; proof/attestation verification error rate (should be ~0); time to receipt anchoring.

Logging and tracing (without a backend)​

Client‑side logs

  • Structured logs emitted to a privacy‑preserving endpoint (or local aggregation) containing no PII and no on‑chain addresses. Redaction is enforced at source; sampling guards volume.

Chain‑derived traces

  • Per‑flow traces constructed client‑side by correlating user actions with transaction IDs, checkpoint numbers, and event IDs. Traces never include decrypted content or identity artifacts.

Auditing and forensics​

Policy and moderation

  • Decisions are anchored as on‑chain events with references to content IDs and policy versions. Catalog changes are tracked via versioned manifests. Evidence for decisions is the combination of on‑chain anchors and (optional) attested receipts.

Bounty lifecycles

  • Each state transition—post, submit (hash anchor), resolve, payout/slash—emits an event. Reputation updates are traceable to specific resolutions.

Alerting and error budgets​

  • Error budgets are defined for user‑visible failures: repeated hash mismatches, content render failures after both paths, sponsored settlement exceeding thresholds, and oracle verification failures.
  • Alerts trigger when SLIs breach SLOs over rolling windows. Triage starts from client telemetry and cross‑checks on‑chain indicators (e.g., spikes in failed effects or Walrus inconsistency events).

Data retention and privacy guarantees​

  • Client logs are retained only as long as necessary for debugging and SLO reporting, then aggregated and anonymized.
  • On‑chain data is permanent by design; sensitive materials are never on‑chain, only hashes and references.
  • Oracle receipts include only measurements/proof artifacts and necessary metadata; no raw inputs are retained on chain.

Tooling​

  • Sui explorer/clients for object and event inspection ([Sui architecture][1]).
  • Walrus tools for PoA and site references ([Walrus][6], [Walrus ops on Sui][9]).
  • Client‑side metrics (web vitals), privacy‑preserving log sinks, and dashboarding oriented around SLIs/SLOs.

[1]–[10]: See References for full citations.