The 2026 audit, checked against the contract running today
The SolidProof audit covered TTSVoting. What runs today is TTSVotingV3d, deployed afterwards. The fixes are claimed to have landed in V3b and carried forward — but “carried forward” is an assumption until something executes it. On 2026-09-25 every finding was re-tested as a behaviour against the live addresses on a Base mainnet fork, not read off a summary.
| ID | Severity | Finding | Against deployed code | Evidence |
|---|---|---|---|---|
C-1 | Critical | Vote cap blocked every vote when the pool was empty | ✓ FIXED (live) | first vote of an empty round succeeded on profile "12a8e551-213f-45ed-841a-b8cd3e14ea20"; round raw votes 0 -> 5 TTS |
H-1 | High | VRF callback gas limit bricked settlement at 500k | ✓ FIXED (live) | CALLBACK_GAS_LIMIT reads 2,500,000 on the deployed contract |
H-2 | High | Zero wallet address could trap funds | ✓ FIXED (live) | rejected: The contract function "batchApproveProfiles" reverted. |
M-3 | Medium | Round unrecoverable if VRF never delivered | ✓ FIXED (live) | adminResetSettlement present; The contract function "adminResetSettlement" reverted with the following reason: |
M-6 | Medium | rolloverRound executed before the round ended | ✓ FIXED (live) | round ends 2026-09-28T04:59:00.000Z; early rollover rejected: The contract function "rolloverRound" reverted with the following reason: |
M-4 | Medium | Single-step ownership with reachable renounceOwnership | ✓ MITIGATED (live) | V3d owner is Keeper3; Keeper3's IVotingV3d interface declares no renounceOwnership and Keeper3 makes no low-level call, so it is unreachable. Direct call from Bank reverts. |
M-2 | Medium | NFT contract could gas-bomb settlement | ✓ FIXED (source, verified on BaseScan) | nftContract = 0x02DDd0e63DC2A5F66Fdb5a46F5981191959AC9A5; mint wrapped in try/catch with gas:200000 in the BaseScan-verified source |
M-1 | Medium | Admin can redirect club share during the VRF window | • ACKNOWLEDGED (live) | Admin is the 2-of-2 Safe; no single-key path. Unchanged by design. |
M-5 | Medium | State changes after external transferFrom in vote() (CEI) | • ACCEPTED — AF-001 | TTS is a plain ERC-20 with no transfer hooks and its address is immutable in V3d, so there is no reentrancy vector. |
M-7 | Medium | Payout destinations mutable during the VRF window | • ACKNOWLEDGED (live) | Requires 2-of-2 signatures. Would be delayed by the proposed 48h timelock. |
T/M-1 | Medium | Token: zero-value transfer reverts (EIP-20 non-compliance) | ! NOT FIXED — LIVE | transfer(B, 0) between two non-exempt addresses: The contract function "transfer" reverted with the following reason:. The fix exists in 0xb995b63c but nothing delegates to it. |
Result: no critical or high-severity finding is live, and nothing live is exploitable. One medium defect remains live — a transfer of exactly zero tokens reverts — and it cannot be patched, because the token is not upgradeable. It is an EIP-20 compliance defect, not a path to anyone's funds.
Reproduce it yourself:
scripts/sale/verify_audit_findings.mjs in the repository, against
anvil --fork-url <base-rpc>. Raw results:
outputs/audit/findings_to_bytecode.json.
What is actually true of the deployed contracts
Each line was checked directly against Base mainnet, or executed against a fork of it, on the date above — not copied from the audit summary.
- The token cannot be upgraded. It is deployed directly, not behind a proxy. What runs today runs permanently.
- No address can be blacklisted. The contract checks a blacklist on every transfer, but contains no function that can write to it. Scanners that flag this are flagging unreachable code.
- The 1% transfer tax cannot be raised. It is a compile-time constant in a contract that cannot be upgraded.
- The 35/35/10/20 split is hardcoded in the voting contract and enforced on every settlement.
- Chainlink VRF picks the winner. Subscription and coordinator are public and verifiable.
- Liquidity is locked on Team.Finance until 2027-05-05.
- Supply is governed, not fixed. A
mint()function exists. MINTER_ROLE has no members today, but the 2-of-2 multisig holds DEFAULT_ADMIN_ROLE and can grant it to itself. We tested this on a mainnet fork and successfully minted. Treat 69,000,000,000 as the current supply, not a cap. - A transfer of exactly zero tokens reverts between two non-tax-exempt addresses, with an arithmetic panic rather than a clean error. This is an ERC-20 compliance defect. A fix was written and deployed as a separate contract, but it never took effect because the token is not upgradeable.
- The voting contract has an accepted reentrancy finding in
vote(). It is not exploitable: $TTS is a plain ERC-20 with no transfer hooks and its address is immutable in the voting contract. Recorded as AF-001.
Anything not on this list has not been independently verified. If you are evaluating this project, read the contracts on BaseScan rather than trusting this page.
Full Report — Solidproof
📄 Published at Solidproof
The full audit report is publicly available at app.solidproof.io/projects/temptation-token. All findings, code snippets, severity ratings, and auditor commentary are included.
Auditor: Solidproof GmbH (Germany) · Audit Date: April 2026 · Methodology: Manual review + automated analysis
Contracts Audited
| Contract | Address | Network | Status |
|---|---|---|---|
| TTS Token (ERC-20 UUPS Proxy) | 0x5570eA…3b9 | Base Mainnet | ✓ Audited |
| TTSVotingV3d (Active) | 0x783b…7b4 | Base Mainnet | ✓ Audited |
| TTSStaking (UUPS Proxy) | 0x7848…c0d | Base Mainnet | Source-verified · deployed after audit |
Solidity version: 0.8.20 · Standards: ERC-20, EIP-1967 (UUPS) · Chain ID: 8453
All Findings by Severity
| ID | Severity | Title | Status |
|---|---|---|---|
| M-1 | Medium | ERC-20 Zero-Value Transfer Tax Issue | Acknowledged ✓ |
| M-2 | Medium | Centralization Risk — Wallet Address Updatability | Acknowledged ✓ |
| M-3 | Medium | Integer Division Rounding in Prize Distribution | Acknowledged ✓ |
The audit raised 1 critical, 3 high, 7 medium and 6 low findings against TTSVoting. C-1 and H-1–H-3 were fixed in V3b, along with M-2, M-3 and M-6. M-1, M-4 and M-7 were acknowledged and not patched; M-5 is recorded as accepted and non-exploitable (a reentrancy pattern that requires a token with transfer hooks — $TTS has none and its address is immutable). On the token, the zero-value-transfer finding was fixed in implementation 0xb995b63c. See the full SolidProof report for the complete text.
Medium Findings — Click to Expand
M-1: ERC-20 Zero-Value Transfer
Acknowledged ✓transfer() and transferFrom() functions apply tax logic even when amount == 0. EIP-20 requires zero-value transfers to succeed without side effects. A fix adding if (amount == 0) return true before tax logic is queued for the next UUPS proxy upgrade through the Gnosis Safe 2/2 multisig. This issue poses no risk to user funds.
M-2: Centralization Risk
Acknowledged ✓M-3: Prize Distribution Rounding
Acknowledged ✓All Contract Addresses — Copy & Verify
Every address below is publicly verifiable on BaseScan. Click copy to get the full address.
TTS Token (UUPS Proxy) — The main $TTS token contract
TTSVotingV3b — Active voting contract (FINAL)
Gnosis Safe — 2/2 multisig treasury
See for yourself — every transaction is on-chain and verifiable at basescan.org