Developers · Developer Trust Center

Evaluate how OMINEX fits into ERC-3643, verification, and attestation delivery workflows.

This Developer Trust Center is built for architects, platform engineers, and technical evaluators. It explains how OMINEX integrates with ERC-3643-compatible workflows, preserves upstream compliance decisions without becoming the gatekeeper, and exposes a neutral attestation layer through APIs, webhooks, transparency-log references, Verifiable Credentials, and on-chain claim writes.

Technical evaluation paths

Go directly to the technical question your team needs to answer.

Use these destinations to move from general product understanding into the exact diligence path needed by engineering, architecture, security, and procurement stakeholders.

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.Transparency log verificationReview how provenance, revocation state, and public proof references support technical and diligence workflows.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.

Technical evaluator path

The goal is not to replace your compliance stack. The goal is to make it portable, provable, and integration-ready.

OMINEX sits between the systems that already make KYC, AML, accreditation, sanctions, or internal policy decisions and the tokenization or verification systems that need to consume those outcomes. The technical evaluation should answer a narrower question: how those decisions become reusable attestation outputs without turning OMINEX into the party that made them.

Request sandbox path Review ERC-3643 model

Technical outcomes

Shorten technical diligence by showing where OMINEX sits between upstream providers and downstream enforcement surfaces.

Reduce architecture confusion by clearly separating attestation normalization from compliance decision-making and identity-data custody.

Give enterprise buyers a cleaner path from product interest into integration review, proof inspection, and sandbox planning.

Integrate with ERC-3643 workflows without becoming the policy gatekeeper

OMINEX can normalize upstream compliance outcomes into ERC-3643-compatible claims, but the issuer, platform, or token logic will still decide which claims issuers are trusted and how policy is enforced.

Keep vendor decisions auditable and portable

The technical value is preserving provenance, timestamps, revocation state, and delivery history so the decisions already made by providers or customer-controlled workflows can move cleanly into verification surfaces.

Support multiple consumption paths from one attestation record

The same normalized attestation can power APIs, webhooks, Verifiable Credentials, transparency-log references, and on-chain claim writes instead of forcing separate downstream models.

Developer Trust Center map

Each page should help a technical buyer answer one concrete diligence question.

ERC-3643 claims

Understand the exact role OMINEX plays in ERC-3643-compatible claim delivery, trusted issuer designation, revocation handling, and tokenization integration.

Transparency log verification

Review how provenance, timestamps, state changes, and public proof references make attestation history inspectable.

Webhooks and delivery

Inspect delivery guarantees, signatures, retry expectations, and how normalized attestations arrive inside customer systems.

Sandbox access

See what a technical evaluation path will look like before production rollout, including architecture review and buyer-specific discovery.

Verifier workflows

Map how platforms, issuers, compliance teams, and downstream verifiers consume attestation outputs operationally.

Example evaluation request

POST /v1/attestations/resolve
content-type: application/json
x-ominex-org: org_demo

{
  "subject": {
    "id": "did:pkh:eip155:1:0x1234...",
    "type": "wallet"
  },
  "workflow": "subscription-eligibility",
  "outputs": ["erc3643", "webhook", "credential", "transparency_log"],
  "topics": ["kyc.pass", "aml.clear", "accredited"],
  "context": {
    "tokenStandard": "erc3643",
    "policyRef": "issuer_policy_us_fund_v3"
  }
}

How this request will be interpreted

A real technical evaluation will usually start with a subject reference, a workflow context, and a list of output surfaces the buyer wants to validate. The response will then describe what upstream decisions were normalized, which proofs are active, and which downstream delivery paths can be exercised first.

Request field

Type

subject.id

Wallet, DID, or customer-controlled subject reference to evaluate.

string

workflow

Business flow the attestation should support, such as subscription, transfer, or servicing.

enum

outputs[]

Delivery surfaces the customer wants to review, including ERC-3643-compatible claims, webhooks, credentials, or transparency-log proof.

array

context.policyRef

Customer-controlled policy or issuer reference that remains authoritative for downstream enforcement.

string

Response field

Type

attestationId

Stable identifier for the normalized attestation envelope.

string

issuerRole

Describes OMINEX as the attestation layer or designated issuer, not the original decision-maker.

string

sourceDecisionMakers[]

Lists the upstream vendors or customer-controlled systems that supplied the underlying decisions.

array

outputs

Returns the delivery-ready surfaces that can be consumed by platform systems and evaluators.

object

How technical evaluations should start

Map the upstream decision sources

Identify which KYC, AML, accreditation, sanctions, or internal decision systems remain authoritative in your operating model.

Choose the delivery surfaces you need

Decide whether the evaluation should focus first on APIs, webhook delivery, transparency-log proof, Verifiable Credentials, or on-chain ERC-3643-compatible claims.

Run the technical evaluation path

Use sandbox planning, architecture review, and verifier workflow walkthroughs to confirm how OMINEX can fit into your existing stack without replacing your current compliance vendors.

Next step

When the technical model is clear, route the team into sandbox planning and trust review.

The best enterprise evaluation path links the developer review directly to trust, procurement, and rollout planning. That is why the Developer Trust Center connects technical pages with sandbox access, architecture review, and the Trust Center rather than treating integration as a disconnected documentation problem.

Plan evaluation Open Trust Center

The strongest technical story is precise about boundaries: upstream providers or customer-owned systems make the compliance decisions, while OMINEX makes those decisions portable, inspectable, and reusable across blockchain compliance workflows.

Build

Ready to evaluate the integration posture?

Start with docs, then move into the architecture and rollout discussion that matches your stack.

View docs Book integration call