Developers · Transparency log verification

Review how OMINEX makes attestation provenance and state changes inspectable.

This page explains the transparency-log side of the technical evaluation. OMINEX is designed to preserve enough provenance, timing, and status history for downstream teams to inspect what happened and what changed, while still leaving original provider workflows and customer trust policy in place.

Continue technical review

Move from proof inspection into the next technical diligence path.

Use the rest of the Developer Trust Center to review claims, webhooks, sandbox planning, and verifier workflows from the same enterprise-evaluation model.

Developer Trust CenterStart with the full technical evaluation path for ERC-3643 integration, delivery surfaces, verifier workflows, and sandbox review.ERC-3643 claimsSee how OMINEX integrates with ERC-3643-compatible workflows without becoming the compliance decision-maker or universal gatekeeper.Webhooks and deliveryUnderstand signatures, retries, event delivery, and how normalized attestations move into customer systems.Sandbox accessFollow the technical evaluation path for architecture review, sandbox planning, and buyer-specific implementation discovery.Verifier workflowsSee how tokenization platforms, issuers, and compliance teams consume attestations operationally without centralizing PII.API and webhook docsMove from the evaluator overview into the broader API and operational reference materials.Architecture and conceptsUnderstand the normalization model, system boundary, and downstream integration posture across the stack.

Why evaluators ask for this

Enterprise buyers do not just want the latest attestation result. They want a reviewable record of where it came from and how it changed.

That is the value of the transparency-log model. It helps engineering, compliance, and audit stakeholders inspect attestation history without collapsing the whole architecture into a single opaque yes-or-no answer. OMINEX is valuable here because it preserves proof context around the decisions already made by provider or customer-controlled systems.

Proof lookup request

GET /v1/transparency-log/attestations/att_01J9ZX...?includeHistory=true&includeSources=true
accept: application/json
x-ominex-org: org_demo

Provenance

Each attestation can preserve where the source signal came from, which provider or customer-controlled workflow supplied it, and when that source was observed.

State history

Evaluators can inspect how attestation status changed over time so the current state is not separated from the operational history behind it.

Revocation visibility

When an upstream provider or customer policy engine updates or withdraws a prior outcome, the downstream proof surface can reflect that revocation state explicitly.

Request field

Type

attestationId

Identifies the normalized attestation record whose proof lineage the team wants to inspect.

path string

includeHistory

Requests a full state-change trail instead of only the current attestation state.

boolean

includeSources

Includes source-system metadata so evaluators can understand which upstream system supplied the decision.

boolean

Example proof response

{
  "attestationId": "att_01J9ZX...",
  "subject": "did:pkh:eip155:1:0x1234...",
  "currentState": "active",
  "revocationState": "active",
  "source": {
    "system": "provider_kyc",
    "decisionRef": "evt_01H..."
  },
  "history": [
    {
      "state": "pending_review",
      "changedAt": "2026-04-28T14:10:03Z"
    },
    {
      "state": "active",
      "changedAt": "2026-04-28T14:22:01Z"
    }
  ],
  "transparencyLogRef": "log_01K..."
}

Technical review checklist

Can engineering and compliance teams inspect what changed without querying the original provider every time?

Can buyers explain to auditors or internal reviewers why a claim was valid at a particular point in time?

Can downstream verifiers reference a public proof trail without forcing OMINEX to hold end-user PII?

Response field

Type

currentState

Returns the latest attestation status available to downstream consumers.

enum

revocationState

Shows whether the upstream decision is still active, replaced, or revoked.

enum

source

Points to the provider or customer-controlled workflow that produced the underlying outcome.

object

history[]

Lists the timestamped state transitions needed for technical and audit review.

array

transparencyLogRef

Stable proof reference for downstream evidence review and auditor discussion.

string

Next step

Proof visibility matters most when it connects directly to delivery and verifier workflows.

After this page, most engineering teams will want to understand how proof-bearing attestations move through webhook delivery and how downstream systems consume them in tokenization or compliance operations.

Review delivery model See verifier workflows

Next step

Move from product curiosity to operating-fit review.

Schedule a buyer review, ask a product question, or start a licensing conversation without digging through extra navigation layers.

Schedule buyer review Licensing & IP