EvidenceGate — Developer Documentation

Overview01

Evidence infrastructure for consequential decisions.

EvidenceGate does not ask validators to merely approve a leader response. Each validator independently fetches, verifies and evaluates the exact bound evidence, then agrees on the exact consequential result.

↳

Use EvidenceGate when

a contract or autonomous agent needs a reusable on-chain attestation derived from policy-approved web evidence with explicit freshness, provenance, corroboration and finality guarantees.

ProvenancePolicy-bound authorities

Authorities are bound to exact addresses and HTTPS publisher origins.

FreshnessVersioned evidence

Stable evidence lineages advance monotonically to prevent stale reuse.

ConsensusExact consequences

No similarity threshold or tolerance may bridge distinct outcomes.

LivenessRepair before rejection

Correctable failures remain repairable and immutable deadlines prevent indefinite openness.

Quickstart02

Integrate in five steps.

The integration path is intentionally small. EvidenceGate produces attestations; your application decides what to do with them.

1
Connect to Bradbury.
Use chain ID 4221 and the canonical contract identity below.
2
Create a sealed policy.
Bind authority IDs, authority addresses, publisher origins, allowed outcomes and numeric limits atomically.
3
Register evidence.
Approved authorities register versioned source records with exact digest, publication time and expiry.
4
Create and resolve a request.
Bind a claim and sorted evidence set, then resolve under GenLayer consensus.
5
Consume safely.
Read the attestation and check is_attestation_current(request_id) before consequential reuse.

Canonical identity

NETWORK    = "GenLayer Bradbury"
CHAIN_ID   = 4221
CONTRACT   = "0xbd403771f876F72540319480EC2453d01de27a2b"
SOURCE_SHA = "6b5c31c786f3b8af0df559ae831b93083dbbe4ee23552a40c268edf633f80ad1"

Architecture03

A deliberately narrow trust surface.

The primitive separates trust selection, evidence publication, consensus derivation and downstream consequence.

Policy authorSeals trust + rules

→

AuthoritiesRegister evidence

→

EvidenceGateVerifies + resolves

→

ConsumersRead current attestation

Scope boundary. EvidenceGate does not custody value, transfer tokens, call external contracts, upgrade itself or automatically settle another application. It is designed to be composed into larger systems.

Core concepts04

The mental model.

01Policy

Immutable rule set binding authorities, origins, outcomes, criteria and freshness/liveness limits.

02Evidence record

Versioned, policy-bound source record with exact digest and expiry.

03Request

Requester-bound claim with an exact evidence bundle and immutable deadline.

04Attestation

Immutable historical result created only from a RESOLVED request.

05Currentness

Live reuse requires the bound evidence to remain latest, fresh and policy-valid.

Contract API05

Compact public surface.

EvidenceGate keeps the integration surface small: six public writes and six public views.

WRITEcreate_policy(...)

Atomically seals authorities, origins, outcomes and numeric bounds.

WRITEregister_evidence(...)

Registers or advances an authority-authenticated evidence lineage.

WRITEcreate_request(...)

Creates an OPEN request after deterministic bundle and deadline validation.

WRITEresolve_request(request_id)

Runs nondeterministic evaluation and persists only consensus-approved state.

WRITErepair_request(...)

Replaces a repairable evidence bundle without extending the original deadline.

WRITEexpire_request(request_id)

Expires unresolved or repairable requests after the deadline.

READget_policy(policy_id)

Returns sealed policy data.

READget_evidence(evidence_id)

Returns exact evidence metadata.

READget_request(request_id)

Returns request state and bound evidence information.

READget_verdict(request_id)

Returns the compact consequential verdict.

READget_attestation(request_id)

Returns immutable resolved attestation data.

READis_attestation_current(request_id)

Checks whether the historical attestation is still safe for live reuse.

!

Integration rule

Never treat the existence of a historical attestation as proof that it is still current. Check is_attestation_current() before consequential use.

Integration recipes06

Composition patterns.

AgentsAutonomous actions

Gate an autonomous action behind a current EvidenceGate attestation.

attestation → policy check → action

MarketsOutcome resolution

Resolve a factual outcome without putting settlement logic inside EvidenceGate.

attestation → market logic

ClaimsEvidence verification

Require corroborated real-world evidence before a downstream claims workflow continues.

attestation → claims workflow

GovernanceFactual inputs

Provide immutable factual input to governance or automation systems.

attestation → governance rule

Failure codes07

Repair instead of false rejection.

Correctable evidence problems should not silently become substantive negative outcomes.

Condition	Meaning	Handling
`SOURCE_FETCH_FAILED`	Source could not be fetched.	Repair with corrected or replacement evidence.
`SOURCE_HTTP_STATUS_NOT_OK`	Source did not return HTTP 200.	Repair; do not attest.
`SOURCE_DIGEST_MISMATCH`	Fetched bytes differ from registered digest.	Repair; exact bytes are mandatory.
`SOURCE_BODY_TOO_LARGE`	Single source exceeds the bounded size.	Use bounded evidence material.
`SOURCE_BUNDLE_TOO_LARGE`	Aggregate evidence exceeds the total bound.	Reduce or replace the bundle.
`CONFLICTING_OR_INSUFFICIENT_EVIDENCE`	No exact allowed outcome is supportable.	Repair with stronger corroboration.

Security model08

What EvidenceGate guarantees—and what it does not.

Enforced by the primitive

Authority address + origin binding
Versioned evidence lineage
Freshness + expiry bounds
Minimum corroboration
Exact validator comparison
Repairable failure states
Immutable deadlines
Historical/current distinction

Explicit trust boundaries

An approved authority is truthful
Different addresses prove independent organizations
Web evidence is always available
LLM evaluation always converges
A URL/hash alone establishes authority
A local test proves live-network finality

Consensus & finality09

Exact consequence, not approximate agreement.

Leader and validators independently execute the bounded fetch/hash/evaluate path. Decision-bearing fields are compared exactly: kind, outcome, failure_code and bundle_digest.

LeaderYESderived result

→

V1 ✓V2 ✓V3 ✓V4 ✓V5 ✓

→

NetworkFinalized|7canonical proof

i

Finality rule

Accepted|5 is provisional. Canonical live proof is based on network Finalized|7 state.

Verification10

Multiple layers, no category errors.

Each layer proves only the properties that belong to it.

01

Source guards + GenVM checks

Syntax, source-security, lint/typecheck and API-shape constraints.

passed

02

Direct Mode

28/28 regression coverage across state, repair, expiry and validator disagreement behavior.

passed

03

Supported runtime

Five validators, 17 finalized writes, positive/negative outcomes, repair/re-resolution and expiry.

passed

04

Reviewer-style audit

No implementation defect found; remaining trust boundaries are explicit.

passed

05

Bradbury live proof

Deployment, policy, evidence, request and resolution all reached Finalized|7.

final

Canonical deployment11

Live Bradbury identity.

These values bind the public documentation to the fixed source and canonical network execution.

Contract0xbd403771f876F72540319480EC2453d01de27a2b

Deployment tx0xa3849f47e9f2e97b7957544407000a996398772dd716ba36bf5f6f1544122a1e

Source SHA-2566b5c31c786f3b8af0df559ae831b93083dbbe4ee23552a40c268edf633f80ad1

Resolve tx0xd04538ea1d0cbb6ea037691a7c4de60fe02f2c0d52bb29b71d31c673e99d773b

Reuse guide12

Reuse the primitive without weakening the guarantees.

Keep invariant

Authority address/origin binding
Immutable policy fingerprint
Latest-version evidence requirement
Freshness and expiry checks
Exact consequential comparison
Repair instead of manufactured rejection
Immutable request deadline
Currentness check before reuse

Customize safely

Policy criteria
Allowed outcome codes
Approved authorities
Publisher origins
Evidence age limits
Request lifetime
Application claim keys
Downstream consumer behavior

FAQ13

Common questions.

Does EvidenceGate prove a source is truthful?+

No. It proves that policy-approved evidence with exact bound bytes was evaluated under the sealed policy and agreed on by validators. Authority truthfulness remains a policy trust decision.

Can one authority satisfy multiple corroboration slots?+

No. Policies require distinct authority IDs backed by distinct addresses and distinct origins for the configured corroboration threshold.

Can I reuse an old resolved attestation forever?+

No. Historical attestations remain queryable, but consequential consumers should verify is_attestation_current().

Does EvidenceGate move funds?+

No. v1 deliberately has no payable surface, custody, transfer, external contract call or automatic settlement behavior.

Glossary14

Terms used throughout the docs.

Finalized|7: The network-final state used by the canonical Bradbury proof.
Accepted|5: A provisional state that must not be described as final.
REPAIR_REQUIRED: A correctable evidence condition that does not manufacture a substantive negative verdict.
Currentness: Whether a historical attestation remains safe for live consequential reuse under current evidence lineage and freshness rules.
Evidence bundle digest: The digest binding a request to its exact evidence set.

Turn verified web evidence into exact, reusable attestations.

Evidence infrastructure for consequential decisions.

Integrate in five steps.

A deliberately narrow trust surface.

The mental model.

Compact public surface.

Composition patterns.

Repair instead of false rejection.

What EvidenceGate guarantees—and what it does not.

Exact consequence, not approximate agreement.

Multiple layers, no category errors.

Live Bradbury identity.

Reuse the primitive without weakening the guarantees.

Common questions.

Terms used throughout the docs.