Plakxio Badge Marketplace: Founder Security Sprint
Zealynx reviewed Plakxio, a gasless marketplace for football match badges on Base, in a two-day Founder Security Sprint against a frozen tag. The scope was the three contracts and their supporting sources: PlakxioBadge, an ERC-1155 walled garden where only a whitelisted settlement contract may move a badge; PlakxioSettlement, which matches relayer-submitted EIP-712 asks and bids and takes payment through EIP-3009 authorizations; and PlakxioSpecialMarket, which runs the ratcheting floor for one-of-one Special badges. The sprint identified 16 issues, including 2 High: any whitelisted operator could take any holder's badges, and a freshly claimed Special was purchasable at a global dust floor. Every finding at Medium or above is backed by a proof-of-concept test paired with a negative control. A remediation review against the next tag found 13 fixed and verified and 3 accepted as risks with reasoning; in two of those three the client argued from their own code and corrected this report, and the corrections are recorded.
Total findings
16
13 fixed · 3 acknowledged
Critical
00
High
02
Medium
06
Low + Info
08
02
Scope
6 files · 1,391 SLOCInitial commit
5c388936dd9c
Final commit
6478a0273737
Platform
Base · Solidity
Methodology
Out of scope
deployment scripts, test suite, off-chain services
File
src/PlakxioSettlement.sol
src/PlakxioBadge.sol
src/PlakxioSpecialMarket.sol
src/PlakxioOrderTypes.sol
src/QuoteTreasuryManaged.sol
src/IERC3009.sol
03
Findings
click any row for the full write-upSeverity
ID
Finding
Status
04
Key Findings
- A whitelisted operator could take any holder's badges, and the holder's refusal was unreadable. The badge answered "approved" for any whitelisted operator against every account, and nothing required that operator to be a contract, so a plain address once whitelisted could move every badge of every permitted class out of any wallet without a signature or a payment. A holder's explicit refusal was written to storage and never read.
- A resting ask could be silently re-priced after it was signed. Fee parameters sat outside the order and were read from live storage at settlement, so an ordinary change to the flat minimum re-priced every resting ask beneath it, with the badge delivered and nothing reverting. Makers are offline by design and had no transaction available to react with.
- A holder could be redeemed on terms they never agreed to. The Special floor was stored as a bare number while the split that redeems it was re-read live, so a routine commission increase retroactively re-priced everyone who had already bought in, on a sale they had no way to decline.
- One mis-scaled administrative call could permanently strand inventory. The opening floor for never-traded Special badges was raise-only, with no upper bound and no inverse, and no role could undo a decimals slip.
05
Architectural Security Observations
- Hardened against the expected adversary, less against two others. The protocol is thoroughly defended against a hostile counterparty at the badge transfer, a code-bearing buyer and an abusive batch submitter, and much less against its own administrator acting normally and the passage of time between a signature and its settlement.
- Values committed to at signing were re-read at execution. The Special floor, the fee parameters, signature validity and the cancel-all epoch are four forms of one defect: a value load-bearing when a party commits, re-read from live storage when the commitment is executed.
- Irreversibility without a bound. A raise-only floor with no ceiling, permanent Special mint flags and single-call admin renunciation were each defensible alone; together they were several one-way doors in a walled garden where badges cannot move by any other route.
- Documentation claimed more than the code. In two places a property was described as closed "by construction" where the code achieves it with a guard. The guards hold; the risk is a later change that trusts the prose and removes one.
06
Security Strengths Observed
- An exceptional adversarial test suite. Eight dedicated suites drive a code-bearing or EIP-7702 buyer against the badge transfer, rejecting, reentering, spinning on gas, forging reverts and detonating returndata and signature bombs. Most teams reach for this class of test after an incident rather than before an audit.
- Comments carry reasoning rather than description, which made it possible to identify exactly where the code and its stated intent diverge.
- Consistent defensive depth. Checks-effects-interactions is documented as load-bearing, the badge transfer is wrapped so a hostile buyer cannot author a revert that frames the seller, and the batch path bounds per-pair gas, total calldata and signature length.
- An unpredictable cancel-all epoch. It advances by an unpredictable jump rather than by one, so a maker cannot pre-sign into the next epoch and have their own cancellation arm the order.
- Accurate self-disclosure. Exposures were declared before the review at their real blast radius, and several of the most useful findings came from testing those stated rationales.
07
Team & approval
Lead Auditor
Carlos (Bloqarl)
@TheBlockChainer
08
Disclaimer
This audit is not an endorsement and does not constitute investment advice. Zealynx reviewed the codebase at the commits listed in section 02 over the engagement window. Findings are limited to issues identified within that scope and do not preclude the existence of other vulnerabilities. Subsequent code changes are not covered by this report unless the engagement is explicitly extended.