# Incorrect decoding in decodeLockTwpTapDstMsg

Tapioca's decodeLockTwpTapDstMsg slices wrong byte lengths for duration and amount, so multiple encodings decode to the same message, breaking codec round-trip integrity.

- Payout: Contest reward
- Severity: medium
- Program: Tapioca DAO
- Credited: GalloDaSballo
- Disclosed: 2024-05-23
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2024-02-tapioca-findings/issues/69
- Library page: https://bugbountylibrary.com/r/c4%3A2024-02-tapioca%3AM-26
- Tags: domain:web3 impact:integrity kind:contest platform:code4rena sev:medium tech:solidity technique:fuzzing technique:source-review vuln:business-logic

**Target:** TapTokenCodec message decoder (Solidity)
**Root cause:** decodeLockTwpTapDstMsg slices duration with length durationOffset_ (32) instead of 12, and amount with _msg.length - durationOffset_ instead of 32, so the decoder reads wrong byte ranges and multiple distinct encodings map to the same decoded struct.
**Steps:**
1. Call `TapTokenCodec.decodeLockTwpTapDstMsg(encoded)` on a crafted message
2. Re-encode via `buildLockTwTapPositionMsg(decoded)`
3. Observe `BytesLib.equal(encoded, ReEncoded)` is false for input `624640ab...eebc1d4c`
4. Fix: slice duration with length `12` and amount with length `32`
**How found:** Fuzzed the codec with Medusa using Recon, asserting encode(decode(x)) == x and finding malformed inputs that break round-trip equality.
**Insight:** Property-test codec round-trips (encode(decode(x))==x) with a fuzzer; mismatched slice lengths in BytesLib.toUintN calls are a common source of non-canonical decoding that can enable message malleability.