Test Explanations

🎓 Understanding Every Test

This page explains what each test does and why it matters for your security.

Total Tests: 950 (753 Hardhat + 181 Foundry + 12 Echidna + 4 Manticore)

Test Categories

1. Token Core Tests (45 tests)

Purpose: Verify the fundamental token operations work correctly.

Deployment Tests (5 tests)

✓ Should deploy with correct initial supply

What it tests: Token starts with exactly 1,296,000,000 S360
Why it matters: Prevents unauthorized token creation
Attack prevented: Infinite token minting exploit

✓ Should distribute to 14 initial wallets

What it tests: Initial allocation goes to correct addresses
Why it matters: Ensures fair launch, no hidden allocations
Attack prevented: Developer backdoor tokens

Transfer Tests (10 tests)

✓ Should allow transfers between accounts
✓ Should fail transfer with insufficient balance
✓ Should prevent transfers to zero address

What they test: Tokens move correctly, balances update, edge cases handled
Why it matters: Core functionality must be bulletproof
Attacks prevented:

• Double spending
• Balance manipulation
• Token burning via zero address

Emergency Pause Tests (4 tests)

✓ Should allow owner to pause
✓ Should prevent transfers when paused
✓ Should allow owner to unpause

What they test: Emergency stop mechanism works
Why it matters: Can halt operations if exploit discovered
Attack prevented: Continuing losses during active attack

2. Staking Security Tests (58 tests)

Purpose: Ensure staking is safe and rewards are fair.

Staking Core (15 tests)

✓ Should allow staking tokens
✓ Should update staked balance
✓ Should prevent staking zero amount

What they test: Users can stake, balances tracked correctly
Why it matters: Users' tokens must be safe when staked
Attacks prevented:

• Stake without tokens
• Double staking
• Stake overflow

Reward Calculation (12 tests)

✓ Should calculate rewards correctly
✓ Should handle compound rewards
✓ Should prevent reward overflow

What they test: Reward math is accurate and safe
Why it matters: Wrong math = stolen rewards or contract drain
Attacks prevented:

• Reward manipulation
• Integer overflow to steal funds
• Reward pool drainage

Reentrancy Protection (8 tests)

✓ Should prevent reentrancy on stake
✓ Should prevent reentrancy on unstake
✓ Should prevent reentrancy on claim

What they test: Functions can't be called recursively
Why it matters: Reentrancy = THE most common DeFi hack
Real-world example: DAO hack (2016) - $60M stolen
Attack prevented: Recursive calls to drain contract

Emergency Withdraw (6 tests)

✓ Should allow emergency withdraw
✓ Should return all staked tokens
✓ Should forfeit rewards on emergency

What they test: Users can always get their principal back
Why it matters: Even if rewards break, principal is safe
Attack prevented: Funds locked forever (rugpull)

3. Bonding Curve Attack Tests (52 tests)

Purpose: Ensure the price mechanism can't be exploited.

Flash Loan Protection (8 tests)

✓ Should enforce MAX_PURCHASE_PER_BLOCK
✓ Should prevent same-block buy and sell

What they test: Can't buy and sell in same transaction
Why it matters: Flash loans can manipulate price
Real-world example: Harvest Finance hack - $34M stolen
Attack prevented: Price manipulation via flash loans

Price Manipulation (12 tests)

✓ Should prevent artificial price pumping
✓ Should enforce slippage protection
✓ Should prevent sandwich attacks

What they test: Price moves fairly, no manipulation
Why it matters: Fair price = fair market
Attacks prevented:

• Front-running
• Sandwich attacks
• MEV extraction

Reserve Backing (10 tests)

✓ Should maintain reserve >= backing_value
✓ Should prevent reserve drain

What they test: Always enough collateral for tokens
Why it matters: Prevents insolvency
Real-world example: Iron Finance collapse - $2B lost
Attack prevented: Bank run / reserve drain

4. Governance Attack Tests (89 tests)

Purpose: Ensure governance can't be hijacked.

Proposal Attacks (25 tests)

✓ Should prevent proposal execution without quorum
✓ Should enforce voting delay
✓ Should enforce timelock on execution

What they test: Can't execute proposals without proper voting
Why it matters: Prevents governance takeover
Real-world example: Beanstalk Farms - $182M stolen via governance
Attacks prevented:

• Flash loan governance attack
• Malicious proposal execution
• Timelock bypass

Voting Manipulation (18 tests)

✓ Should prevent double voting
✓ Should prevent delegation loops
✓ Should prevent vote buying

What they test: Votes are counted correctly, can't be duplicated
Why it matters: One token = one vote (democracy)
Attacks prevented:

• Sybil attacks
• Vote manipulation
• Delegation chain exploits

Timelock Attacks (12 tests)

✓ Should enforce minimum delay
✓ Should prevent timelock bypass
✓ Should prevent queue manipulation

What they test: Proposals can't execute immediately
Why it matters: Gives community time to react
Attack prevented: Instant malicious proposal execution

Sandwich Attacks (8 tests)

✓ Should prevent proposal state manipulation
✓ Should prevent execution frontrunning

What they test: Can't manipulate proposal execution order
Why it matters: Fair execution = fair governance
Attack prevented: MEV on governance actions

5. Economic Invariant Tests (28 tests)

Purpose: Mathematical properties that MUST always be true.

Token Conservation

✓ Total supply = sum of all balances

What it tests: Tokens don't appear or disappear
Why it matters: Conservation of value
If this breaks: Tokens being created from nothing

Staking Invariants

✓ Rewards pool ≥ pending rewards
✓ Total staked ≤ contract balance

What they test: Can't pay out more than pool has
Why it matters: Contract must remain solvent
If this breaks: Unable to pay rewards (bankrupt)

Bonding Curve Invariants

✓ Reserve ≥ backing_value(supply)
✓ Price = f(supply) is monotonic

What they test: Price follows curve, reserve sufficient
Why it matters: Mathematical guarantees
If this breaks: Price manipulation or insolvency

6. Foundry Tests (181 tests)

Purpose: Test with 1.00M+ random inputs to find edge cases.

Property-Based Testing

✓ testFuzz_TransferPreservesTotalSupply (10,000 runs)

What it tests: ANY transfer amount, from/to address = supply unchanged
Why it matters: Catches edge cases humans miss
How it works: Runs 10,000 random scenarios

Invariant Testing

✓ testInvariant_BalancesAlwaysNonNegative (10,000 runs)

What it tests: Balances can NEVER go negative
Why it matters: Negative balance = broken accounting
How it works: Tries to break it 10,000 different ways

Real-World Impact

Why Each Category Matters

Total value protected: $276M+ (based on similar past exploits)

Test Methodology

How We Write Tests

1. Identify Attack Vector

   • Research real hacks
   • Analyze vulnerability reports
   • Study attack patterns

2. Write Exploit Test

   • Code the actual attack
   • Try to steal/manipulate/break

3. Verify Protection

   • Test should FAIL (attack blocked)
   • If test passes = vulnerability found

4. Document

   • Explain what it prevents
   • Link to real-world examples

Example: Reentrancy Test

it("Should prevent reentrancy on unstake", async function() {
  // Setup: Attacker deploys malicious contract
  const attacker = await MaliciousContract.deploy(staking);
  
  // Step 1: Attacker stakes tokens
  await staking.connect(attacker).stake(ethers.parseEther("1000"));
  
  // Step 2: Attacker tries to unstake recursively
  // (calls unstake() again before first call finishes)
  await expect(
    attacker.attackUnstake()
  ).to.be.reverted; // ✅ Attack blocked
  
  // Verify: Attacker only gets their stake once
  const balance = await token.balanceOf(attacker.address);
  expect(balance).to.equal(ethers.parseEther("1000")); // Not 2000
});

What this prevents: The DAO hack (2016) that stole $60M

Coverage Analysis

What Gets Tested

Coverage (current):
- Overall (incl. mocks): 61.22%
- Core contracts avg:    84.41%

Breakdown details are available in the contracts repo coverage outputs.

Uncovered Code (1.5%)

The 1.5% uncovered consists of:

1. Emergency circuit breakers - Can't test without breaking production
2. Governance emergency pause - Requires multisig (tested manually)
3. Self-destruct prevention - Solidity 0.8+ prevents this by default

Uncovered code is reviewed manually; core contracts are additionally validated with invariant-style tests and extensive attack scenarios.

How to Verify Tests Yourself

# Clone repo
git clone https://github.com/JaisonKeiver/seal360-contracts.git
cd seal360-contracts
 
# Install dependencies
npm install
 
# Run specific test
npx hardhat test test/SEAL360Token.exhaustive.test.cjs
 
# Run all tests
npm test
 
# Run with gas reporting
npm run test:gas
 
# Run coverage
npm run coverage

Test Evolution

Questions?

Want to Understand a Specific Test?

1. View test source code on GitHub → (opens in a new tab)
2. Ask in Discord → (opens in a new tab)
3. Open a discussion → (opens in a new tab)

Report a Test Gap?

Found a scenario we're not testing?

• Submit a test request → (opens in a new tab)
• Bug bounty program →

Next Steps

• View complete test outputs →
• View security tool reports →
• View CI/CD pipeline →