Self-hosted validators on Post Fiat-style networks publish an xrp-ledger.toml-equivalent discovery file at their domain root. That file proves operator control of the validator — it does not tell anyone who the operator is, how they run the node, or how they handle incidents. This spec defines a reusable operator profile template that goes beyond discovery: identity disclosure, infrastructure transparency, accountability surfaces, on-chain attestation, and privacy-safe TOML extensions. The audience is human delegators deciding whether to trust an operator and automated evaluators parsing the page programmatically. This is link three in a chain that began with the Validator Failure Response Manifest and continued with the Validator Failure Classification Matrix. Manifest defines what to do when things break. Matrix defines how to identify what broke. This spec defines how to publish who you are before any of that is needed.

The Practical Problem

A discovery file alone leaves the most important questions unanswered. Who runs this validator? Where does it live? How will the operator surface an incident? What happens if the operator goes silent? A trustline holder, a delegator, or a scoring agent landing on a validator's domain page should be able to answer all four questions in under a minute. Most validator pages do not let them.

The fix is not a longer discovery file. The fix is a small, structured operator profile published alongside the discovery file, with a clear separation between what is required, what is optional, and what should never be disclosed.

Example Operator Profile

This is what the page should look like. Every section below the example unpacks one block of it.

Bigwood Node

Self-hosted Post Fiat-style validator. Operated by walkonwayvs since 2026.

Bio: Independent self-hosted validator operator focused on reliability, transparency, and privacy-safe infrastructure.

Operator handle: walkonwayvs Public contact: x.com/OnWavs Validator public key: nHByMXejvHJgjcGJ1f9bhcAGcFeNR6ecsDmzN4t3HkhyRHZtM6Lj Domain: bigwoodnode.com Discovery file: bigwoodnode.com/.well-known/xrp-ledger.toml

Infrastructure

• Provider: DigitalOcean
• Region: Toronto (CA)
• Operating system: Ubuntu 22.04 LTS
• Container runtime: Docker
• Monitoring: Discord webhook on healthcheck container
• Uptime posture: 24/7 with auto-restart on process exit; manual rejoin required for cluster authorization failures

Specific droplet specs, IP addresses, internal network topology, and SSH configuration are intentionally omitted. Public-facing infrastructure disclosure ends at provider and region.

Incident Disclosure Posture

This operator commits to surfacing operational incidents that affect consensus participation, agreement scores, or downtime exceeding 30 minutes. Incidents are classified using the Validator Failure Classification Matrix and resolved using the Validator Failure Response Manifest. Incident notes are posted to this page within 72 hours of resolution, with class ID, duration, and resolution path. No private node data is published.

On-Chain Attestation

The operator's signed manifest is published in the discovery file at /.well-known/xrp-ledger.toml. The manifest binds this domain to the validator public key above. To verify: fetch the discovery file, extract the [[VALIDATORS]] block matching this public key, and confirm the attestation field is signed by the same key.

Optional TOML Extensions

[[OPERATOR]]
handle = "walkonwayvs"
contact = "https://x.com/OnWavs"
incident_disclosure_url = "https://bigwoodnode.com/#incidents"
manifest_url = "https://www.publish0x.com/reviews-ravens-writing-desks/validator-failure-response-manifest-xywmwmr"
matrix_url = "https://www.publish0x.com/reviews-ravens-writing-desks/validator-failure-classification-matrix"
profile_version = "1.0"

That is the entire profile. The blocks below explain each section and define the rules.

Section: Operator Profile (Identity)

The first block establishes who runs the node. Required: operator handle, at least one public contact, and the validator public key. The handle should be a stable identifier — not a personal real name unless the operator chooses to disclose, and not a one-off anonymous string. Public contact is a channel where the operator can be reached publicly: a social handle, a federated profile, or a signed mailto with a clear response posture. The validator public key is the cryptographic anchor — without it the rest of the page has nothing to bind to.

Omit: legal name, physical address, phone number, email addresses tied to identity recovery on other systems, and any handle from an unrelated identity an operator does not want linked. An operator who runs the validator under one handle and writes about it under another keeps them separate on the page.

Example:

Operator handle: walkonwayvs Public contact: x.com/OnWavs Validator public key: nHByMXejvHJgjcGJ1f9bhcAGcFeNR6ecsDmzN4t3HkhyRHZtM6Lj

Section: Infrastructure Transparency

The point of this section is to give a delegator confidence the node is run with operational seriousness without giving an attacker a target. Disclose at the provider and region level. Disclose the operating system and container runtime if they are mainstream choices. Disclose the monitoring posture in general terms. Disclose the uptime commitment.

Omit: IP addresses, specific droplet or instance specs, internal network topology, SSH key fingerprints, exact hostnames, port numbers, firewall rules, and any path that would let an attacker map the node's surface area. The general rule: an attacker reading this section should learn nothing they could not have learned from a public scan.

Example:

Provider: DigitalOcean Region: Toronto (CA) OS: Ubuntu 22.04 LTS Monitoring: Discord webhook on healthcheck container Uptime posture: 24/7 with auto-restart; manual rejoin for cluster authorization failures

Section: Contact and Accountability

A page that establishes who the operator is and how they run the node still leaves one gap: what happens if the operator stops responding. This section closes it. State a public contact channel, a response-time expectation, and an escalation path if the primary channel goes silent.

Omit: personal email addresses, phone numbers, or anything that ties contact to identity recovery on unrelated systems. A federated handle, a public Twitter account, or a forum profile is sufficient. An operator who wants higher accountability can list a secondary channel — a co-signed bridge contact, a Discord handle, or a published GPG key for signed messages — but more channels are not better if they cannot all be monitored.

Example:

Primary contact: x.com/OnWavs Response time: within 48 hours for non-urgent, within 12 hours for incidents affecting consensus participation Escalation: if no response within 96 hours during an active incident, this validator may be considered unreliable until the operator surfaces a status update

Section: Incident Disclosure Posture

This is the section that separates an operator profile from a vanity page. State a commitment to surface operational incidents that affect the network. Define the threshold (e.g., downtime > 30 minutes, agreement score deviation, version drift, cluster exclusion). State the publication path (a section on this page, a feed, a pinned post on the public contact). State the timeline (within 72 hours of resolution is reasonable for non-emergencies; faster for active critical events).

The disclosure should always include the failure class, duration, and resolution path. It should never include private node data, peer identifiers from other operators, or any information that could enable an attack on the broader network.

Example:

Incidents affecting consensus participation, agreement scores, or downtime > 30 minutes are surfaced here within 72 hours of resolution. Format: class ID (per the Matrix), duration, resolution path. No private node data published.

Section: On-Chain Attestation

The cryptographic step that turns the profile from a claim into a verifiable claim. The operator publishes a signed manifest binding the domain to the validator public key. Anyone can verify by fetching the discovery file, parsing the [[VALIDATORS]] block matching the public key, and checking the signature against the published key.

This section on the operator page does not need to repeat the manifest itself — that lives in the discovery file at /.well-known/xrp-ledger.toml. It just needs to point readers to where the attestation is and tell them how to verify it.

Example:

The operator's signed manifest is published at /.well-known/xrp-ledger.toml. To verify: fetch the file, locate the [[VALIDATORS]] block matching the public key above, confirm the attestation field is signed by the same key.

Section: Optional TOML Extensions

Automated evaluators parse machine-readable fields, not prose. The optional [[OPERATOR]] block in the discovery file gives evaluators a structured surface for everything in the operator profile that benefits from being parsed: handle, contact, incident disclosure URL, links to the operator's published response and classification frameworks, and a profile version string for forward compatibility.

The block is optional because not every operator publishes additional frameworks. The fields that are present should be stable URLs, not links to a feed that might rotate.

Example:

[[OPERATOR]]
handle = "walkonwayvs"
contact = "https://x.com/OnWavs"
incident_disclosure_url = "https://bigwoodnode.com/#incidents"
manifest_url = "https://www.publish0x.com/reviews-ravens-writing-desks/validator-failure-response-manifest-xywmwmr"
matrix_url = "https://www.publish0x.com/reviews-ravens-writing-desks/validator-failure-classification-matrix"
profile_version = "1.0"

An evaluator parsing this block can resolve the operator's published incident-handling commitments without scraping prose.

Copyable Operator Profile Template

### [Validator Name]

*Self-hosted Post Fiat-style validator. Operated by [HANDLE] since [YEAR].*

**Bio:** [one line, optional]

**Operator handle:** [HANDLE]
**Public contact:** [URL or federated handle]
**Validator public key:** `[PUBLIC KEY]`
**Domain:** [DOMAIN]
**Discovery file:** [DOMAIN]/.well-known/xrp-ledger.toml

**Infrastructure**
- Provider: [PROVIDER]
- Region: [REGION]
- OS: [OS]
- Container runtime: [if applicable]
- Monitoring: [general description]
- Uptime posture: [commitment in plain language]

**Incident Disclosure Posture**
[Commitment statement: threshold, publication path, timeline. No private node data.]

**On-Chain Attestation**
[Pointer to discovery file location and verification steps.]

**Optional TOML Extensions**
[[OPERATOR]] block in /.well-known/xrp-ledger.toml — see spec.

Reviewer Checklist (PASS / WARN / FAIL)

Ten items. Each is a binary check. WARN is for items that are present but partial; FAIL is for items missing entirely.

1. Operator handle present. A stable identifier. PASS if present, FAIL if absent.
2. Public contact present. At least one publicly reachable channel. PASS if present and resolvable, FAIL if absent.
3. Validator public key present and matches discovery file. PASS if both. WARN if present but unverified. FAIL if absent.
4. Discovery file linked. Direct link to /.well-known/xrp-ledger.toml or equivalent. PASS or FAIL.
5. Infrastructure disclosure at provider+region level only. PASS if disclosed at the right granularity. WARN if over-disclosed (specific IPs, specs, ports). FAIL if absent.
6. No prohibited disclosures. No legal name unless operator chose to publish, no IPs, no SSH keys, no internal hostnames. PASS or FAIL.
7. Incident disclosure commitment present. Threshold, publication path, timeline. PASS if all three, WARN if partial, FAIL if absent.
8. On-chain attestation explained. Clear pointer to where the manifest lives and how to verify. PASS or FAIL.
9. Optional [[OPERATOR]] TOML block present in discovery file. PASS if present and parses. WARN if present but malformed. FAIL if absent (optional, so FAIL is non-blocking).
10. Page loads without login or paywall. PASS or FAIL.

A profile passing all ten is fully compliant. A profile passing 1-8 with WARN or FAIL on 9 is acceptable. A profile failing any of 1-8 is incomplete.

Closing

This spec is reusable. Any self-hosted Post Fiat-style validator can adopt it, fill the template, publish the result, and pass the checklist in under an hour. The point is not the page. The point is that delegators, evaluators, and the network itself can answer four questions about an operator before trusting them with consensus participation: who runs this, where does it live, how will incidents surface, and what happens if the operator goes silent. A profile page that answers those questions in a format both humans and machines can parse is operator infrastructure. A page that does not is decoration.