Proof-of-Trust consensus
Quidnug does not produce a single globally-agreed chain. Each node tiers incoming blocks based on its own trust in the validator:
| Tier | Condition | Behavior |
|---|---|---|
| Trusted | Trust in validator ≥ domain threshold | Added to main chain; transactions applied |
| Tentative | Between distrust and trust thresholds | Stored separately; not built on |
| Untrusted | Below distrust threshold | Only trust-edge data extracted |
| Invalid | Cryptographic verification fails | Rejected outright |
Why different nodes see different chains
Section titled “Why different nodes see different chains”Alice trusts validators A and B. Bob trusts A and D. They agree on A-sealed blocks. They disagree about B’s and D’s, which is correct, because they disagree about those parties.
This is not Byzantine Fault Tolerance. It is trust-aware consensus where the observer’s context determines acceptance. It fits domains where “one chain for everyone” isn’t the goal, private, consortium, or federated deployments, where parties legitimately disagree about who to trust.
When is this correct?
Section titled “When is this correct?”When your problem has this property: the same event should be accepted by some parties and not others, because they do not agree on who is authorized to speak. Examples:
- A medical consortium where different hospitals trust different CA roots, an attestation signed by one root should be accepted by its customers and rejected by others.
- A cross-jurisdictional election where different counties trust their own officials, a precinct block from county A’s official should land in county A’s chain and be tentative (or ignored) from county B’s view.
- A vendor-neutral fraud signal consortium where merchants trust their own rankings of reporters, one merchant’s “confirmed fraud” signal may be another’s “unverified noise”.
When is this not the right model?
Section titled “When is this not the right model?”- You need a single globally-agreed ledger. Use a BFT or Nakamoto-style chain.
- You have no initial trust seeding and no out-of-band channel to bootstrap relationships.
- You require a single universal score for a subject, Quidnug deliberately refuses to produce one.
Related design proposals
Section titled “Related design proposals”- QDP-0001: Global Nonce Ledger per-signer monotonic nonces enforce replay safety even under tiered acceptance.
- QDP-0008: K-of-K Snapshot Bootstrap fresh nodes seed state from a quorum of trusted peers instead of a single source.
- QDP-0009: Fork-Block Migration Trigger coordinated protocol upgrades land on the chain at a future block height so all operators activate in lockstep.
- QDP-0010: Compact Merkle Proofs light clients verify anchors with ~70% less gossip bandwidth.
See also the system overview and rogue-node security write-up.