🫵Slashing & Challenger System

Purpose

Ensure data validity and computation integrity by enabling any participant to challenge dishonest or incorrect submissions (e.g., invalid datasets, forged proofs, malicious inference). If proven correct, the challenger is rewarded, and the malicious party is penalized through slashing.

• Fraud Detection: Any party can submit a FraudProof against a committed block.

• Resolution:

  • LazChain executes a fraud arbitration contract using on-chain or TEE-based verification.

  • If the proof is valid:

    • Proposer is slashed

    • Validating signers are penalized (if collusion proven)

    • Challenger is rewarded

Core Components

Component	Role
Proposer	The validator/quorum member who proposed the block or submitted the AI asset/proof.
Challenger	Any external actor who submits evidence that a committed dataset, proof, or result is invalid or fraudulent.
Arbitration Contract	A smart contract that validates fraud proofs (ZK, Merkle, TEE attestations) and enforces punishment/reward.
Slashing Pool	Staked tokens held by proposers and quorum validators, which can be reduced (slashed) in the event of fraud.
Challenge Window	The period (e.g., 100 blocks) during which a committed block/result can be challenged.

---

Challenge Flow

Step 1: Fraud Detection

A challenger observes that a committed dataset, model, or inference result is invalid.

Examples:

• Malformed or manipulated dataset hash

• Proof mismatch (ZK, OP)

• Inference result contradicts source input

They prepare a Fraud Proof:

struct FraudProof {

bytes32 disputedBlockHash;

bytes challengeData; // could be Merkle branch, ZK transcript, etc.

uint256 timestamp;

address challenger;

}

Step 2: Challenge Submission

The challenger calls:

challengeBlock(bytes32 disputedBlockHash, FraudProof calldata proof)

The contract:

• Checks challengeWindow validity (block not too old)

• Validates the proof.challengeData

• Calls appropriate verifier (e.g., MerkleVerifier, ZKVerifier, TEECertifier)

Step 3: Arbitration & Result

If the fraud proof is valid:

Action	Effect
🏆 Challenger wins	Receives reward from slashing pool (e.g., 10% of stake)
⛔ Proposer slashed	Their stake is burned or redistributed
⚠️ Quorum Validators (optional)	Can be penalized (reduced rewards, stake slashing) if collusion proven
❌ Fraudulent block/result	Marked invalid, removed or reverted in local state
🧠 DATs minted	May be burned or frozen if tied to fraudulent data

If the fraud proof is invalid:

• The challenger may lose a small bond (anti-spam)

• Block and proposer remain valid

Challenge Types

Type	Description	Verifier
ZK Challenge	Submitted proof is invalid or unverifiable	ZKVerifier
TEE Challenge	TEE signature or report mismatch	TEECertifier
Inference Discrepancy	Output does not match expected inference	OP / Result Replay
Dataset Integrity	Dataset hash does not match anchor	MerkleVerifier
Behavioral Fraud	Agent performs unauthorized behavior (e.g. overcharge, illegal write)	AgentAuditContract

Slashing Logic

Actor	Condition	Slash Amount (example)
Proposer	Proven to have submitted invalid block/proof	30%–100% of stake
Validator	Signed off on invalid block (optional check)	10%–30% if collusion
Challenger	Submitted invalid challenge	Forfeit 1%–5% challenge bond

Challenge Timing Parameters

Parameter	Description	Example Value
challengeWindow	Max blocks after proposal that a challenge is valid	100 blocks
verificationTimeout	Max time for contract to verify a proof	1 minute
slashingDelay	Delay before applying slashing, to allow appeals	10 blocks

Integration with DAT

• Fraudulent data detected → affected DAT tokens are frozen or burned.

• Ownership reverted or flagged in registry.

• Affected classId can be blacklisted temporarily.

• Future token mints in that class may require stronger verification (e.g., quorum + external verifier).

Incentive Summary

Role	Incentive
Challenger	Wins reward from slashed stake if proof is valid
Validator	Earns block rewards, but penalized for signing off on invalidity
Proposer	Gets rewards if honest, slashed if caught submitting invalid work
iDAO	Maintains reputation and stake power through accurate participation

Example

Dataset submitted with wrong hash, minted as DAT.

A challenger finds the original file on IPFS and submits a Merkle branch proving mismatch.

challengeBlock() is called, validated → proposer slashed, challenger rewarded, DAT frozen.