Security-review and harden the existing SwarmWorld Core design. This is NOT a new protocol and NOT a token project.

Existing system: SwarmWorld is an on-chain world with 3 settlements and resource state. Missions are worked by distinct builder, tester, reviewer and verifier roles. A mission records artifact hashes and a deterministic proofHash. Settlement state changes only after successful verification.

Your task: Produce a hardened SwarmWorld Solidity implementation with Foundry tests. Preserve the existing architecture unless a security fix requires a change.

Contracts:

• SwarmWorld: settlement/world state.
• MissionManager: mission lifecycle, escrow/rewards, verification and settlement.

Audit these issues specifically:

1. activeMission cleanup A settlement must never remain permanently locked after a mission reaches a terminal state.

Clear activeMission correctly after SETTLED, FAILED, EXPIRED or any other terminal path.

Test that a new mission can be created after each terminal state.

2. Mission state machine Enforce valid transitions only: OPEN -> WORKING -> VERIFYING -> PASSED/FAILED -> SETTLED where applicable.

No caller may skip required stages or settle twice.

3. Expiry Expired missions must have a deterministic terminal path.

Expiry must not leave funds or settlements permanently locked.

Test before/after deadline behavior.

4. Escrow accounting Never distribute more than the funded reward.

Successful settlement pays exactly: builder 50%

tester 15%

reviewer 15%

verifier 20%

Prevent double payout, double refund and double claim.

Failed/expired missions must have a safe refund path.

5. Reentrancy Protect all ERC20 payout/refund paths.

Use checks-effects-interactions and ReentrancyGuard where appropriate.

6. Roles builder, tester, reviewer and verifier must be nonzero and distinct.

A participant cannot review or verify their own work.

Enforce caller permissions for every stage.

7. World-state safety Resources energy, food, materials and knowledge must always remain 0..1000.

Stability must remain 0..100.

Invalid signed deltas must revert safely.

World state must NOT change when builder submits work, tester reviews, or verifier passes.

Apply state transition only during final successful settlement.

8. activeMission and mission IDs Handle missionId 0 safely.

Prevent duplicate or conflicting active missions for one settlement.

9. proofHash Keep a deterministic proofHash committing to:

chainId,

missionId,

settlementId,

specHash,

pre-state hash,

builder artifact hash,

test artifact hash,

review artifact hash,

verifier artifact hash,

proposed transition,

builder/tester/reviewer/verifier addresses.

Document clearly that proofHash is an evidence commitment, NOT proof that the underlying work is objectively true.

10. Identity.MD provenance If seat IDs are stored, do NOT claim the contract proves wallet ownership of an Identity.MD seat unless such verification is actually implemented.

Document seat IDs as provenance metadata only.

Testing: Use Foundry unit tests plus fuzz tests and invariant tests.

Required invariants:

• settlement resources always stay within bounds
• escrow never pays more than funded
• each mission settles at most once
• terminal missions cannot lock a settlement forever
• world state changes only through valid final settlement
• role permissions cannot be bypassed

Include adversarial tests for: unauthorized calls,

self-review,

self-verification,

duplicate proof/artifact submissions,

double settlement,

double refund,

reentrancy,

expired missions,

invalid state transitions,

resource overflow/underflow,

missionId 0,

ERC20 transfer failure.

Do not invent IMD oracle, consensus or cryptographic capabilities that are not implemented.

Deliver:

• hardened Solidity source
• complete Foundry test suite
• fuzz/invariant tests
• deployment script
• ABI
• README
• SECURITY.md listing