# Matez staking: integer truncation enables free token claims

Matez staking contract integer truncation let attacker stake huge amount that truncated to zero, then claim free MATEZ tokens via referrals, netting 80k USD.

- Payout: Real-world hack
- Severity: high
- Program: Matez
- Credited: DeFiHackLabs
- Disclosed: 2024-11-21
- Write-up quality: 6/10
- Original: https://github.com/SunWeb3Sec/DeFiHackLabs/blob/main/src/test/2024-11/Matez_exp.sol
- Library page: https://bugbountylibrary.com/r/dhl%3A20241121-matez
- Tags: domain:web3 impact:funds-loss kind:incident platform:defihacklabs sev:high tech:evm technique:source-review vuln:business-logic vuln:precision-loss

**Target:** Matez staking contract on BSC
**Root cause:** Staking amount is stored in a smaller integer type (likely uint128 or similar) causing truncation to zero for large values, while the contract still records a large staked amount for reward calculations.
**Steps:**
1. Call `register(sponsor)` on Matez staking contract.
2. Call `stake(340282366920938463463374607431768211456)` (2^128) which truncates to 0 in storage but is treated as large stake.
3. Deploy 25 AttackContract instances, each calling `register(sponsor)` and `stake(2^128)` to create referrals.
4. Call `claim(uint40(3), uint40(1), 0)` to receive free MATEZ tokens.
5. Repeat claim process to accumulate more tokens, then sell for profit.
**Exploitation:** Attacker registered with a sponsor, staked 2^128 tokens (truncated to 0), created 25 referral contracts each staking the same amount, then called claim to receive MATEZ tokens for free, repeating to drain funds.
**Escalation:** Used multiple referral contracts to meet claim requirements and amplify token extraction.
**Insight:** Look for integer type mismatches in staking/reward contracts where large input values truncate to zero but are still counted as valid stakes; test with 2^128 or similar boundary values.