Status: done (on-chain registry mechanics superseded — probation/ban enforcement uses tracker registry + ADR-0015/0018)

# 08 — Node probationary period + ban enforcement

## What to build

Implement the two anti-sybil mechanisms that make re-entering the network after a ban economically costly.

**Probationary period**: a new wallet's first N completed inference jobs earn no token rewards. N is a configurable on-chain parameter (default: 50 jobs). The settlement contract reads the wallet's job count and skips reward distribution until the threshold is met. The node client displays the remaining probationary job count on startup.

**Ban enforcement**: when a wallet's strike count reaches the configured threshold, the registry contract marks it as banned. The tracker and gateway must check ban status on every route selection and exclude banned wallets. Ban status is read exclusively from the Solana registry contract — the tracker cannot set or unset bans.

Both mechanisms together mean a banned node operator must: create a new wallet, fund a new stake, and complete N free jobs before earning again — a meaningful economic barrier.

## Acceptance criteria

- [ ] A node with a new wallet receives no token rewards for its first N jobs (verified via settlement contract state)
- [ ] The node client prints remaining probationary jobs on startup (e.g. "Probationary period: 38 jobs remaining before earning")
- [ ] After N jobs, the next epoch settlement correctly credits the node with token rewards
- [ ] A wallet with strike count at the threshold is marked banned in the registry contract
- [ ] The tracker excludes banned wallets from route selection
- [ ] A banned wallet that attempts to register with the tracker is rejected
- [ ] An integration test covers: new wallet → N jobs → earning begins; and: strike threshold reached → banned → excluded from routes

## Blocked by

- `07-fraud-detection-slash.md`