Domains

Domains give trust context. They use DNS-like dot-notation, read right-to-left:

contractors.home.services
doctors.credentials.texas.medical-board.gov
oracles.price-feeds.ethereum.mainnet

A trust edge is declared in a domain. Querying trust requires specifying the domain, and the answer is scoped to it:

A ──0.9, domain=contractors.home──► B

Why domains

Without a domain, trust becomes a single universal score, which is exactly what Quidnug is designed not to produce. By requiring a domain, the protocol forces applications to be honest about context:

• “I trust Alice at 0.9 for home contracting” ≠ “I trust Alice for medical advice”.
• “I trust this oracle at 0.95 for ETH/USD price” ≠ “I trust it for on-chain governance votes”.

Inheritance

Domains can inherit along the parent/child axis when it makes sense. A node may “walk up” the domain tree to find authorities when a specific subdomain’s registry isn’t populated. Whether inheritance applies to a query is configurable per-domain, some applications want strict scoping, others want fallback.

Domain authorities

A domain can designate authorities via a domains configuration or via trust edges at the domain root. Authorities are relevant primarily for Proof-of-Trust block acceptance decisions; see consensus.

Practical recommendations

• Pick domain names that look like what they are. credentials.physician.hospital-xyz.state-ca.gov is better than a random UUID.
• Align domain depth with authority granularity. Don’t bury the trusted authority ten levels deep.
• Reserve a top-level segment for your organization (e.g. <service>.example.com) so domain collisions across federated deployments can’t happen.

Cross-domain gossip

When a key rotation happens in one domain, QDP-0003: Cross-Domain Nonce Scoping and QDP-0005: Push-Based Gossip ensure fingerprints propagate so signatures remain verifiable across peered domains.