# Bonded Guarantee Manifest

**Status:** DRAFT PROPOSAL v0.1  
**Created:** 2026-06-01  
**Authors:** LogicNodes (open for contribution)  

> **Live reference manifest:** The authoritative, real-valued Bonded Guarantee Manifest for LogicNodes is published at [`/.well-known/bgm.json`](https://logicnodes.io/.well-known/bgm.json) and is independently verifiable on Base mainnet. The worked example in §4 below uses LogicNodes' real on-chain values; the JSON at `/.well-known/bgm.json` is authoritative if the two ever differ. As of publication LogicNodes has earned **$0.00 external revenue and 0 external paid verdicts** — the bond is real and funded, the track record is honestly empty.

**Discussions-To:** (pending)  
**Category:** Interoperability / Agent Trust Infrastructure  
**Requires:** ERC-8004, x402, CAIP-10, A2A AgentCard  

---

## Abstract

This document specifies the **Bonded Guarantee Manifest** (BGM) — a machine-readable JSON object that allows any AI agent or service provider to declare that a service guarantee is backed by a slashable on-chain bond. The manifest provides a standardized schema for expressing: the identity of the bond issuer, the on-chain contract address and asset held in escrow, the conditions under which the bond may be slashed, the identity of the entity whose signed verdicts trigger slashing, the procedure by which a challenger may initiate a slash, and the manifest's expiry. The BGM is designed to compose with Google's Agent-to-Agent (A2A) protocol's `AgentCard`, with the ERC-8004 Validation Registry, and with the x402 HTTP payment standard. It does not replace any of these; it fills a gap none of them address: a portable, verifiable, cross-chain-capable declaration that a promise is economically bonded.

---

## Motivation

AI agents increasingly make service-level promises — quality thresholds, accuracy rates, SLA commitments — on behalf of or to other agents and human principals. Several trust primitives now exist in parallel:

- **A2A (Google, 2025):** Defines how agents advertise capabilities via a structured `AgentCard` at `/.well-known/agent-card.json`. The `AgentCard` schema covers identity, skills, authentication, and endpoint routing, but contains no field for economic accountability or on-chain bond references.

- **ERC-8004 "Trustless Agents" (Ethereum Foundation + Consensys, finalized October 2025):** Specifies three on-chain registries — Identity (ERC-721 NFT), Reputation (feedback attestations), and Validation (independent verification via TEE oracles, stake-secured validators, or zkML proofs). ERC-8004 explicitly excludes payment flows from its scope.

- **x402 (Coinbase, 2025):** Defines an HTTP 402-based protocol for USDC settlement on Base, enabling per-call micropayments between agents. x402 handles the movement of funds but does not model the conditions under which funds are forfeited as a penalty.

The result is a gap: an agent can register its identity (ERC-8004), advertise its skills (A2A), and receive payment (x402), but there is no standard mechanism to declare, in a way a downstream agent or human can verify without trust, that a specific guarantee is backed by bonded collateral that is permissionlessly slashable if the guarantee is violated.

Absent such a standard, bonding arrangements remain bespoke and opaque. An agent or service that *does* post a bond cannot communicate that fact in a machine-readable way that other agents can parse, verify, and act upon. This proposal addresses that gap.

---

## Specification

### 1. Overview

A Bonded Guarantee Manifest is a JSON document, signed by the `issuer`, that is either:

1. Embedded in the `extensions.bonded_guarantee` field of an A2A `AgentCard`, or
2. Hosted at a well-known URL and referenced by URI from an `AgentCard` or an ERC-8004 Validation Registry entry, or
3. Returned inline in an x402 payment response header as a compact reference object (see §5.3).

The manifest is self-describing: a consumer needs only this document, a JSON Schema validator, and a standard EVM RPC endpoint to verify the bond exists and is sufficient.

---

### 2. JSON Schema

```json
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://bonded-guarantee-manifest.org/schema/v0.1/bgm.json",
  "title": "BondedGuaranteeManifest",
  "type": "object",
  "required": [
    "manifest_version",
    "issuer",
    "bond_contract",
    "asset",
    "amount",
    "currency",
    "slashable_conditions",
    "verdict_signer",
    "dispute_process",
    "verification_steps",
    "expiry"
  ],
  "properties": {
    "manifest_version": { "type": "string" },
    "issuer":           { "type": "object" },
    "bond_contract":    { "type": "string" },
    "asset":            { "type": "object" },
    "amount":           { "type": "string" },
    "currency":         { "type": "string" },
    "slashable_conditions": { "type": "array" },
    "verdict_signer":   { "type": "object" },
    "dispute_process":  { "type": "object" },
    "verification_steps": { "type": "array" },
    "expiry":           { "type": "string" }
  }
}
```

---

### 3. Field Definitions

#### `manifest_version` *(string, required)*

Semantic version string identifying the BGM schema version used. This specification defines version `"0.1"`. Consumers MUST reject manifests with a major version they do not recognize.

**Example:** `"0.1"`

---

#### `issuer` *(object, required)*

Identifies the entity that signed and posted the bond. Contains:

| Sub-field | Type | Required | Description |
|---|---|---|---|
| `name` | string | RECOMMENDED | Human-readable name of the issuer. |
| `url` | string (URI) | RECOMMENDED | Canonical URL of the issuer's service. |
| `erc8004_identity` | string (CAIP-10) | OPTIONAL | The ERC-8004 Identity Registry token address + token ID for the issuer, expressed as a CAIP-10 asset reference. Allows consumers to cross-reference the issuer's on-chain identity without trusting the manifest alone. |
| `agent_card_url` | string (URI) | OPTIONAL | URL of the A2A `AgentCard` for the issuing agent. |
| `signing_address` | string (EIP-55 checksummed address) | REQUIRED | The Ethereum address whose private key was used to sign this manifest. Consumers MUST verify the manifest signature against this address. |

---

#### `bond_contract` *(string, required)*

A [CAIP-10](https://github.com/ChainAgnostic/CAIPs/blob/main/CAIPs/caip-10.md) account identifier pointing to the smart contract that holds the bonded collateral and implements the slash interface. CAIP-10 format: `{chain_id}:{account_address}`.

Using CAIP-10 makes the manifest chain-agnostic: the same schema covers contracts on Base mainnet, Base Sepolia, Ethereum mainnet, or any EVM-compatible chain.

**Example:** `"eip155:8453:0xb1037D0A49A474596c0192aC8e93d4A8732553b7"`

---

#### `asset` *(object, required)*

Describes the bonded asset. Contains:

| Sub-field | Type | Required | Description |
|---|---|---|---|
| `caip19` | string | REQUIRED | CAIP-19 asset identifier for the token held in the bond contract. |
| `token_name` | string | RECOMMENDED | Human-readable token name (e.g., `"USDC"`). |
| `decimals` | integer | RECOMMENDED | Token decimal precision. Consumers use this to interpret `amount`. |

**Example (USDC on Base):**
```json
{
  "caip19": "eip155:8453/erc20:0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
  "token_name": "USDC",
  "decimals": 6
}
```

---

#### `amount` *(string, required)*

The quantity of `asset` currently held in the bond contract, expressed as a decimal string in the token's smallest unit (i.e., applying `decimals`). Using a string avoids floating-point precision loss.

**Example:** `"5000000000"` (representing 5,000 USDC at 6 decimal places)

> **Note:** `amount` is a *declared* value at manifest issuance. Consumers MUST independently verify the live on-chain balance via `verification_steps` rather than trusting this field alone.

---

#### `currency` *(string, required)*

ISO 4217 currency code or well-known ticker symbol corresponding to `asset`. Used for human display and for x402 integration where a fiat-denominated payment context applies.

**Example:** `"USDC"`

---

#### `slashable_conditions` *(array of objects, required)*

An ordered list of conditions that, if proven, entitle a challenger to initiate a slash. Each condition object contains:

| Sub-field | Type | Required | Description |
|---|---|---|---|
| `id` | string | REQUIRED | Opaque, stable identifier for this condition within this manifest (e.g., `"WRONG_VERDICT"`). Referenced in `dispute_process`. |
| `description` | string | REQUIRED | Plain-language description of the condition. |
| `proof_type` | string (enum) | REQUIRED | Mechanism by which the condition is proven on-chain. One of: `"ecdsa_counter_signature"`, `"zk_proof"`, `"tee_attestation"`, `"oracle_report"`, `"governance_vote"`. |
| `evidence_schema` | string (URI) | OPTIONAL | URI to a JSON Schema describing the evidence package a challenger must submit to the bond contract. |
| `slash_fraction` | string | OPTIONAL | Fraction of the bonded amount slashed if this condition is triggered, as a decimal string between `"0"` and `"1"`. If absent, the contract determines the fraction. |

---

#### `verdict_signer` *(object, required)*

Identifies the cryptographic signer whose signed outputs are used as the authoritative source of truth against which `slashable_conditions` are evaluated. In evaluator-style architectures (e.g., LogicNodes VerdictBond), verdicts are ECDSA-signed off-chain and submitted on-chain during a dispute.

| Sub-field | Type | Required | Description |
|---|---|---|---|
| `address` | string (EIP-55) | REQUIRED | The Ethereum address of the verdict signer. |
| `role` | string | RECOMMENDED | Human-readable description of the signer's role (e.g., `"Bonded Evaluator"`). |
| `public_key_url` | string (URI) | OPTIONAL | URL to retrieve the signer's public key or DID document for offline verification. |

---

#### `dispute_process` *(object, required)*

Describes the end-to-end process by which a challenger initiates a slash. Contains:

| Sub-field | Type | Required | Description |
|---|---|---|---|
| `challenge_window_seconds` | integer | REQUIRED | Duration in seconds after a verdict or service event during which a challenge may be filed. After this window the bond is considered non-slashable for that event. |
| `challenge_interface` | string (enum) | REQUIRED | How a challenge is submitted. One of: `"contract_call"`, `"http_endpoint"`, `"governance_proposal"`. |
| `challenge_endpoint` | string (URI or CAIP-10) | REQUIRED | If `"contract_call"`: CAIP-10 address of the slash entrypoint (may equal `bond_contract`). If `"http_endpoint"`: URL accepting a signed challenge payload. |
| `challenge_function_sig` | string | CONDITIONAL | ABI function signature of the on-chain slash function. Required if `challenge_interface` is `"contract_call"`. Example: `"slash(bytes32 verdictId, bytes signature, bytes evidence)"`. |
| `required_conditions` | array of strings | REQUIRED | Array of `slashable_conditions[].id` values that must be satisfied to trigger a slash. |
| `arbitration` | object | OPTIONAL | If disputes may escalate to an arbitration layer (e.g., an optimistic fraud window or an on-chain DAO), describes it here. Sub-fields: `type` (string), `url` (URI). |

---

#### `verification_steps` *(array of objects, required)*

An ordered list of steps a consumer SHOULD execute to independently verify the bond is live and sufficient before relying on the manifest. Each step object contains:

| Sub-field | Type | Required | Description |
|---|---|---|---|
| `step` | integer | REQUIRED | Execution order (1-indexed). |
| `action` | string (enum) | REQUIRED | One of: `"eth_call"`, `"fetch_url"`, `"verify_signature"`, `"check_erc8004_registry"`. |
| `description` | string | REQUIRED | Human-readable description of what this step verifies. |
| `params` | object | REQUIRED | Action-specific parameters (see below). |

**`eth_call` params:**

```json
{
  "to":   "<CAIP-10 address>",
  "data": "<hex-encoded calldata>",
  "expected_return_type": "uint256 | bool | address"
}
```

**`verify_signature` params:**

```json
{
  "message_hash_algorithm": "eip191 | eip712",
  "signer_address": "<EIP-55 address>",
  "message_template": "<string with {variable} placeholders>"
}
```

---

#### `expiry` *(string, required)*

ISO 8601 UTC datetime after which this manifest is considered stale and consumers MUST NOT rely on it without re-fetching a fresh manifest from the issuer. The bond itself may persist beyond `expiry`; this field governs manifest freshness, not bond existence.

**Example:** `"2026-12-31T23:59:59Z"`

---

#### Optional Top-Level Fields

| Field | Type | Description |
|---|---|---|
| `scope` | array of strings | Service SKUs, skill identifiers, or endpoint paths this bond covers. If absent, the bond covers all services offered by the issuer. |
| `metadata_url` | string (URI) | URL of a human-readable description of the bonding program. |
| `manifest_signature` | string | Hex-encoded ECDSA signature of the canonical JSON (excluding this field itself, keys sorted, no whitespace) by `issuer.signing_address`. Consumers SHOULD verify this. |
| `previous_manifest_hash` | string | Keccak-256 hash of the immediately preceding manifest version, enabling an auditable chain of manifest revisions. |

---

### 4. Full Worked Example: LogicNodes / VerdictBond

The following is a complete BGM for LogicNodes, populated against the live VerdictBond contract at `0xb1037D0A49A474596c0192aC8e93d4A8732553b7` on Base mainnet (chain ID 8453).

```json
{
  "manifest_version": "0.1",
  "issuer": {
    "name": "LogicNodes",
    "url": "https://logicnodes.io",
    "signing_address": "0x73EbAF4939929FeB26AE8756143E27dd37b028c9",
    "agent_card_url": "https://logicnodes.io/.well-known/agent-card.json"
  },
  "bond_contract": "eip155:8453:0xb1037D0A49A474596c0192aC8e93d4A8732553b7",
  "asset": {
    "caip19": "eip155:8453/erc20:0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
    "token_name": "USDC",
    "decimals": 6
  },
  "amount": "10000000",
  "currency": "USDC",
  "slashable_conditions": [
    {
      "id": "WRONG_VERDICT",
      "description": "LogicNodes issued a signed evaluator verdict that is demonstrably incorrect. A challenger provides a counter-signed verdict from a second bonded evaluator plus supporting evidence that contradicts the original verdict on a point of verifiable fact.",
      "proof_type": "ecdsa_counter_signature",
      "evidence_schema": "https://logicnodes.io/schemas/counter-verdict-evidence-v1.json",
      "slash_fraction": "1.0"
    },
    {
      "id": "MISSED_SLA",
      "description": "LogicNodes failed to deliver a signed verdict within the agreed response window for a paid evaluation request confirmed via x402.",
      "proof_type": "oracle_report",
      "evidence_schema": "https://logicnodes.io/schemas/sla-miss-evidence-v1.json",
      "slash_fraction": "0.1"
    }
  ],
  "verdict_signer": {
    "address": "0x73EbAF4939929FeB26AE8756143E27dd37b028c9",
    "role": "Bonded Evaluator",
    "public_key_url": "https://logicnodes.io/.well-known/verdict-signer.json"
  },
  "dispute_process": {
    "challenge_window_seconds": 604800,
    "challenge_interface": "contract_call",
    "challenge_endpoint": "eip155:8453:0xb1037D0A49A474596c0192aC8e93d4A8732553b7",
    "challenge_function_sig": "slash(bytes32 verdictId, bytes counterSignature, bytes evidence)",
    "required_conditions": ["WRONG_VERDICT"],
    "arbitration": {
      "type": "optimistic_window",
      "url": "https://logicnodes.io/docs/dispute-resolution"
    }
  },
  "verification_steps": [
    {
      "step": 1,
      "action": "eth_call",
      "description": "Call bondBalance() on the VerdictBond contract and confirm the returned uint256 meets or exceeds the declared amount.",
      "params": {
        "to": "eip155:8453:0xb1037D0A49A474596c0192aC8e93d4A8732553b7",
        "data": "0xd4c3f0b2",
        "expected_return_type": "uint256"
      }
    },
    {
      "step": 2,
      "action": "eth_call",
      "description": "Call isSlashable() on the VerdictBond contract and confirm the bond has not already been fully slashed or withdrawn.",
      "params": {
        "to": "eip155:8453:0xb1037D0A49A474596c0192aC8e93d4A8732553b7",
        "data": "0x1a2b3c4d",
        "expected_return_type": "bool"
      }
    },
    {
      "step": 3,
      "action": "verify_signature",
      "description": "Verify that manifest_signature is a valid EIP-191 signature of the canonical manifest JSON by issuer.signing_address.",
      "params": {
        "message_hash_algorithm": "eip191",
        "signer_address": "0x73EbAF4939929FeB26AE8756143E27dd37b028c9",
        "message_template": "canonical JSON of manifest excluding manifest_signature field"
      }
    },
    {
      "step": 4,
      "action": "fetch_url",
      "description": "Fetch the issuer's AgentCard and confirm the bonded_guarantee field references this manifest's content hash.",
      "params": {
        "url": "https://logicnodes.io/.well-known/agent-card.json",
        "expected_field": "extensions.bonded_guarantee.manifest_hash"
      }
    }
  ],
  "expiry": "2026-12-31T23:59:59Z",
  "scope": ["evaluation", "verdict"],
  "metadata_url": "https://logicnodes.io/docs/bonding-program",
  "manifest_signature": "0x<hex-encoded-signature>"
}
```

---

## 5. Consumption

### 5.1 A2A AgentCard Integration

An agent advertising bonded guarantees via A2A SHOULD add the following to its `AgentCard` JSON (at `/.well-known/agent-card.json`):

```json
{
  "extensions": {
    "bonded_guarantee": {
      "manifest_url": "https://example-agent.io/.well-known/bgm.json",
      "manifest_hash": "0x<keccak256-of-canonical-manifest-json>",
      "summary": {
        "bond_contract": "eip155:8453:0x...",
        "currency": "USDC",
        "amount_display": "5000",
        "expiry": "2026-12-31T23:59:59Z"
      }
    }
  }
}
```

The `manifest_hash` field allows a consumer to fetch the manifest and verify its integrity without trusting the transport layer. `summary` is informational only; the canonical values are in the manifest itself.

A consuming agent workflow is:

1. Discover AgentCard at `/.well-known/agent-card.json`.
2. Check `extensions.bonded_guarantee` is present and `expiry` is in the future.
3. Fetch manifest from `manifest_url`.
4. Verify `keccak256(canonical_json)` matches `manifest_hash`.
5. Execute `verification_steps` in order.
6. If all steps pass, treat the guarantee as bonded for the duration of the session.

### 5.2 ERC-8004 Validation Registry Composition

ERC-8004's Validation Registry stores attestations that an agent has been independently verified. A BGM reference can be embedded in the attestation's `metadata_uri` payload. The attestation record's `attestation_type` field SHOULD be set to a new type identifier `BGM_V0` (pending ERC-8004 governance registration), and `metadata_uri` should point to the canonical BGM JSON.

This enables a consumer querying the ERC-8004 Validation Registry to discover not only *that* an agent has been validated, but *what economic backing* underlies that validation — without requiring any out-of-band communication.

A TEE oracle or zkML verifier operating within ERC-8004's Validation Registry MAY also verify `verification_steps` on-chain as part of its attestation logic, effectively anchoring the BGM's claims to the same trust guarantees as ERC-8004's stake-secured verification layer.

### 5.3 x402 Integration

When a paying agent receives an HTTP 402 response under the x402 protocol, the response headers MAY include a `X-Bonded-Guarantee-Manifest` header containing either:

- A URL to the full BGM, or
- A compact inline JSON object with `bond_contract`, `amount`, `currency`, `expiry`, and `manifest_hash` fields.

This allows payers to verify that a service is bonded before authorizing a USDC payment. x402 implementations SHOULD treat a valid, unexpired BGM as increasing the trustworthiness tier of the payee, which MAY unlock higher per-call payment limits in risk-managed payer policies.

---

## Security Considerations

**Stale `amount` declarations.** The `amount` field in the manifest is a snapshot at signing time. An issuer could post a bond, sign a manifest, then withdraw the bond. Consumers MUST execute `verification_steps` — specifically the `eth_call` to verify live balance — before relying on the manifest. The `expiry` field limits the window of potential staleness but does not eliminate the need for live verification.

**Signing address compromise.** If `issuer.signing_address` is compromised, a fraudulent manifest could be issued. Issuers SHOULD use a dedicated signing key separate from their bond-controlling key. Key rotation must be accompanied by a new manifest with an updated `manifest_signature`. Consumers SHOULD cross-check against the ERC-8004 Identity Registry when available.

**Slash condition gaming.** Slashable conditions stated in natural language (`description`) create interpretive surface area. Issuers SHOULD accompany each condition with a machine-verifiable `evidence_schema` that constrains what counts as valid evidence. Conditions without `evidence_schema` SHOULD be treated by consumers as carrying higher dispute risk.

**Challenge window manipulation.** An issuer might offer a very short `challenge_window_seconds`, making practical slashing difficult. Consuming agents SHOULD treat windows shorter than a minimum threshold (suggested: 3 days / 259,200 seconds) as insufficient and surface this to the requesting principal.

**Re-entrancy and contract risks.** The slash function in the bond contract is a live smart contract interaction. Challengers MUST review the bond contract code before submitting a slash transaction. This specification does not mandate a specific bond contract implementation; the security of the bond is entirely a function of the referenced contract.

**Manifest replay.** A BGM signed today is valid until `expiry`. Consumers SHOULD bind a BGM to a specific session or transaction by requiring the issuer to co-sign a session nonce alongside the manifest. This is out of scope for v0.1 but noted for future revisions.

**Griefing via spurious challenges.** If challenging is cheap, adversaries might submit spurious slash attempts to harm a legitimate issuer's reputation or consume their gas. Bond contracts SHOULD require challengers to stake a modest deposit that is forfeited if the challenge fails; this spec encourages (but does not require) that `dispute_process` documents this.

---

## Relationship to ERC-8004, A2A, and x402

### ERC-8004

ERC-8004 provides on-chain identity and reputation infrastructure for agents. The BGM is not a replacement or extension of ERC-8004's registries; it is a *payload* that can be referenced from within ERC-8004's Validation Registry attestations. ERC-8004 answers "has this agent been verified?"; the BGM answers "what happens economically if the verified agent's guarantees are false?" These are complementary, not overlapping.

### A2A (Google Agent-to-Agent Protocol)

The A2A `AgentCard` is the discovery surface where agents advertise capabilities to one another. The BGM extends this discovery surface with economic accountability data, using the `extensions` field that A2A explicitly reserves for ecosystem-defined metadata. No changes to the A2A core schema are required.

### x402 (Coinbase HTTP 402 Protocol)

x402 governs payment flows between agents denominated in USDC on Base. The BGM is concerned with *penalty* flows — what happens when a paid service fails. The two protocols operate at different points in the agent interaction lifecycle: x402 fires before service delivery (authorization and settlement), while a BGM slash fires after a proven failure. Together, x402 and BGM provide a more complete financial accountability layer: pay for service via x402, hold the provider accountable via BGM if the service is defective.

---

## Open Questions for v0.2

The following issues are deferred to future revisions:

1. **Standardized bond contract interface.** This spec references bond contracts by CAIP-10 but does not mandate an ABI. A companion ERC defining a minimal `IBondedGuarantee` interface (with `bondBalance()`, `isSlashable()`, `slash(...)`) would allow consumers to use a single verification adapter.

2. **Cross-chain bond references.** CAIP-10 supports non-EVM chains in principle. The verification_steps model assumes EVM RPC access; a generalisation for Solana, Cosmos, or other chains is needed.

3. **Session-binding.** As noted in Security Considerations, binding a BGM to a specific session nonce would reduce replay risk.

4. **Revocation registry.** There is currently no standard on-chain registry for revoked BGMs. An issuer who loses their signing key has no way to invalidate a fraudulent manifest. A lightweight revocation mapping in the ERC-8004 Identity Registry is a candidate solution.

5. **Partial coverage declarations.** The `scope` field allows scoping a bond to specific services, but there is no mechanism to declare that different sub-services carry different bond sizes. Future versions may support an array of coverage objects each with their own `amount`.

---

## References

- **ERC-8004 "Trustless Agents"** — Ethereum Foundation + Consensys, finalized October 2025. On-chain registries for agent identity, reputation, and validation.
- **x402** — Coinbase, 2025. HTTP 402-based USDC micropayment protocol for AI agents. [https://x402.org](https://x402.org)
- **A2A (Agent-to-Agent Protocol)** — Google, 2025. Protocol for agent capability discovery and inter-agent communication. [https://google.github.io/A2A](https://google.github.io/A2A)
- **CAIP-10** — Chain Agnostic Improvement Proposal 10, account identification standard. [https://github.com/ChainAgnostic/CAIPs/blob/main/CAIPs/caip-10.md](https://github.com/ChainAgnostic/CAIPs/blob/main/CAIPs/caip-10.md)
- **CAIP-19** — Chain Agnostic Improvement Proposal 19, asset identification standard. [https://github.com/ChainAgnostic/CAIPs/blob/main/CAIPs/caip-19.md](https://github.com/ChainAgnostic/CAIPs/blob/main/CAIPs/caip-19.md)
- **LogicNodes VerdictBond** — Contract at `0xb1037D0A49A474596c0192aC8e93d4A8732553b7` on Base mainnet (chain ID 8453). [https://logicnodes.io](https://logicnodes.io)
- **EIP-55** — Mixed-case checksum address encoding. [https://eips.ethereum.org/EIPS/eip-55](https://eips.ethereum.org/EIPS/eip-55)
- **EIP-191** — Signed data standard. [https://eips.ethereum.org/EIPS/eip-191](https://eips.ethereum.org/EIPS/eip-191)
- **EIP-712** — Typed structured data hashing and signing. [https://eips.ethereum.org/EIPS/eip-712](https://eips.ethereum.org/EIPS/eip-712)

---

*This document is a DRAFT PROPOSAL. It has not been adopted by any standards body. Field definitions, schema identifiers, and URIs are illustrative and subject to change in future revisions. No adoption claims are made on behalf of any party.*