Node Attestation & Consensus Security

This page documents the concrete cryptographic mechanisms that secure who may attest to protocol results, how those attestations are trusted, and how privileged changes are gated. It describes real primitives that are in the code and (where noted) deployed on Base Sepolia today; it is not a roadmap.

Status (testnet): Noderr is live on Base Sepolia (current phase, Q4 2026). The signature, quorum, Merkle-proof and timelock mechanisms below are implemented and deployed on testnet. A third-party external audit is scheduled for Q1 2027 and is not yet complete, so these controls should be read as "implemented and internally reviewed," not "independently audited."

1. Oracle attestation signatures (ECDSA / EIP-191)

Off-chain results - strategy performance, TrustFingerprint updates, reward epochs - are not trusted on face value. Each is signed by an oracle key using ECDSA over the secp256k1 curve, encoded with the EIP-191 personal_sign scheme, and the on-chain verifier recovers the signer address from the signature before accepting the payload.

  • Node and AI-agent registration uses the same primitive: the server issues a single-use, time-limited nonce, and the operator returns an EIP-191 signature over the full message, which is verified on-chain to bind the wallet to the identity.
  • Signatures are single-use and nonce-bound, so a captured signature cannot be replayed.

2. BFT signature quorum

No single oracle can move capital or finalize a result. Attestations are accepted only on a Byzantine-Fault-Tolerant supermajority of signing weight - the consensus contracts require 67% of the oracle signing set to agree before an attestation is treated as final. A minority of faulty or malicious signers cannot force an outcome, and the quorum is measured in signing weight, not raw key count.

3. Merkle reward proofs

Reward distributions are published as a Merkle root rather than a long list of on-chain writes. Each operator claims by supplying a Merkle proof against the published root; the MerkleRewardDistributor contract (0xCcDB471823C4F14Ffa4814641eafDa63fb526834 on Base Sepolia) verifies the proof and pays out. This makes every distribution independently verifiable and keeps a claim cheap and tamper-evident: an operator can confirm their entry against the root without trusting the distributor's word for it. Rewards are paid by transfer from pre-funded reward pools - no new tokens are minted to fund them.

4. Hardware attestation (TPM / RSA / SHA-256)

The node client establishes device integrity through hardware attestation. Where a Trusted Platform Module (TPM) or equivalent secure element is available, the client produces an attestation quote signed with an RSA device key and hashed with SHA-256, binding the running node identity to trusted hardware. Sensitive strategy logic that a Guardian or Oracle handles is kept inside a secure enclave, so the code and parameters can be evaluated without being exposed to the operator or the public. This is what lets the protocol publish verifiable performance while the underlying strategy stays private.

5. Governance & upgrade gate (multi-sig + 7-day timelock)

Privileged changes - contract upgrades and core-parameter changes - cannot be executed unilaterally or instantly:

  • Core-contract admin and upgrade authority is held by a 2-of-3 Gnosis Safe acting through a MultiSigTimelock with a 7-day standard delay. The timelock is the DEFAULT_ADMIN and UPGRADER of the core contracts, so this is the only path that can upgrade them or change privileged parameters.
  • Community-facing decisions (elections, parameter votes) are settled by on-chain node voting: 10% quorum, 60% standard approval, and a 66% Oracle-Chamber supermajority for major decisions (treasury / capital deployment, large allocations, strategy approval, Oracle elections). Passed proposals are queued behind the timelock (2 days default, up to 7; 24-hour emergency fast-track) before they can execute.

The delay is the point: it gives node operators and the community a window to review, and to trigger incident response if a queued action is hostile.

What this does not rely on

For clarity about what is and is not in use: Noderr's node attestation and consensus security rests on the standard, auditable primitives above - ECDSA/EIP-191 signatures, a BFT signing quorum, Merkle proofs, hardware (TPM) attestation, and a timelocked multi-sig. It does not depend on zero-knowledge proofs; performance privacy is achieved through secure enclaves and threshold handling, not ZK circuits. Third-party infrastructure referenced elsewhere in these docs (for example external rollup/data-availability providers) is described in its own sections and is not part of this attestation path.

See Also:

results matching ""

    No results matching ""