Plakxio: Restoring Consent to ERC-1155 Transfers

The answer in 30 seconds

Plakxio directly engaged Zealynx for a two-day Founder Security Sprint on its gasless football-badge marketplace on Base. Sellers signed orders off-chain while a platform relayer submitted settlement transactions, so the ERC-1155 badge contract had to let approved settlement contracts move badges without making sellers hold gas.[1]

The pivotal issue was that PlakxioBadge treated whitelist membership as universal approval. Any whitelisted address—not necessarily a contract—could move any holder's permitted badge classes without an order signature or payment, while a holder's explicit revocation was stored but ignored. Zealynx tested the complete grant-to-transfer path. The remediation review verified three connected controls: settlement operators must contain code, new grants wait through an activation delay, and holder opt-outs are enforced on both single and batch transfers.[2]

This is a public-evidence technical engagement narrative, not a customer transformation story. It makes no claim about exploitation, monetary exposure, deployment, or Plakxio's private outcomes.

The buyer decision: where should gasless consent be enforced?

Plakxio's reviewed marketplace separated intent from execution. Buyers and sellers signed EIP-712 orders, a relayer submitted them, PlakxioSettlement matched the orders and handled EIP-3009 payment authorization, and PlakxioBadge allowed only whitelisted settlement operators to move badges. The review covered six Solidity files and 1,391 source lines at initial commit 5c388936dd9ce51824032c08c658a7a30457df05, with remediation reviewed at 6478a0273737d9a06b3f1d8b2d811279aaa6ab9f.[1]

For a gasless marketplace, removing an on-chain approval step can improve the seller experience. It also moves the consent boundary: the asset contract no longer obtains permission directly from the holder and must instead prove that every privileged operator enforces signed intent.

The security invariant was:

Only a consent-enforcing settlement contract may exercise transfer authority, and a holder's explicit opt-out must stop that authority on every transfer path.

The dangerous assumption: a whitelist restriction is also consent

PlakxioBadge.isApprovedForAll(account, operator) returned true whenever operator appeared in the settlement whitelist. That override applied to every holder account. The class mask limited which kinds of badge an operator could move, but it did not establish whose badge the operator could move or whether that holder had signed an order.[2]

The intended PlakxioSettlement contract checked EIP-712 signatures. The badge contract, however, did not require a whitelisted address to be that implementation—or even to contain code. An administrator could grant a plain externally owned account the same ERC-1155 authority.

A second inconsistency made the boundary harder to observe: a holder could call setApprovalForAll(operator, false) and receive a successful transaction and event, but the whitelist branch still made isApprovedForAll return true. The interface reported an opt-out action that did not alter effective authority.

How the connected failure path worked

The public finding demonstrates the authorization gap as one state-transition sequence:[2]

1. A holder owns badges and explicitly records setApprovalForAll(grantee, false).
2. An administrator whitelists grantee with a class mask.
3. The grant takes effect immediately, and grantee need not contain contract code.
4. isApprovedForAll(holder, grantee) returns true because whitelist membership overrides the stored refusal.
5. The whitelisted address calls safeBatchTransferFrom for the permitted badge classes.
6. The class gate and ERC-1155 authorization check both pass without an order signature or payment.

The failure was not simply an overpowered administrator. Administration was already trusted. The missing property was that a privileged grant could not express or enforce the intended constraint: authority belonged only to a consent-checking settlement mechanism, subject to a holder-readable opt-out.

How Zealynx tested the invariant

1. Trace authority from configuration to asset movement

The review followed setSettlementContract through the class gate, the isApprovedForAll override, and OpenZeppelin's ERC-1155 transfer authorization. This connected an administrative configuration call to the exact condition that allowed badge movement.[2]

2. Replace the expected contract with the weakest valid address

The whitelist accepted an address, not a behavioral guarantee. Testing a plain externally owned account showed that signature enforcement in PlakxioSettlement was not an invariant of PlakxioBadge; it was only a property of the expected operator.

3. Compare observable revocation with effective revocation

The review checked both the stored approval event and the authorization result. The holder's refusal existed in storage but was unreachable because the whitelist branch resolved first.

4. Exercise both transfer surfaces after remediation

The resolution records that holder opt-out was enforced on the view and on both single and batch transfer paths. The original proof-of-concept steps were rerun against the fix and closed.[2]

Before, intervention, and verified after-state

The finding is marked fixed. That status applies to the reviewed remediation and proof-of-concept path; it does not establish production deployment or guarantee the absence of other vulnerabilities.[2]

What the remediation changed—and what remains configurable

The fix did not replace gasless settlement with per-order on-chain approvals. It added layered constraints around the delegated model:

• operator identity: a new settlement address must contain code;
• time to react: activation is delayed instead of immediate;
• holder agency: an explicit opt-out changes both the reported approval and transfer behavior;
• surface consistency: the control applies to single and batch transfers;
• signal accuracy: a zero class mask no longer reads as approval.[2]

The public resolution also records two limits. The activation delay is a constructor argument with no lower bound, so a zero deployment value would remove the time buffer. Consent remains opt-out rather than opt-in, so a holder who has not refused still depends on correct whitelist administration and settlement behavior.[2]

A reusable review model for privileged NFT operators

Teams designing gasless ERC-721 or ERC-1155 transfers should test the delegated authority as a complete lifecycle:

1. Grant: Can an operator be an EOA, an unexpected implementation, a proxy with changeable behavior, or an address with an empty class scope?
2. Activation: Can the grant and asset movement occur atomically, or is there a review and cancellation window?
3. Consent: Where is the holder's signed intent verified, and does the asset contract enforce that verifier structurally or only assume it?
4. Revocation: Does an opt-out change effective authorization, not merely storage and events?
5. Coverage: Do identical rules apply to single transfers, batch transfers, burns, and any custom movement path?
6. Observability: Do isApprovedForAll, events, indexers, and wallets report the authority that transfer functions actually enforce?
7. Deployment bounds: Are safety-critical delay and role parameters constrained against zero or unsafe values?
8. Emergency removal: Can a bad operator be disabled immediately without waiting through the activation rule?

The transferable lesson is that a whitelist proves membership, not consent. If the asset contract grants blanket authority, the system needs code-enforced constraints on who may receive it, when it activates, how holders refuse it, and which movement paths consume it.

Impact and evidence limits

The strongest supportable outcome is finding-specific: the remediation review records that the demonstrated route from an unconstrained whitelist grant to non-consensual single or batch badge movement was closed by the three controls above.[2]

The public evidence does not show that the path was exploited, that a malicious operator was ever whitelisted, that any badge or monetary value was lost or preserved, or that the remediated code was deployed. The wider sprint recorded 16 findings—13 fixed and three acknowledged—but this narrative does not turn that inventory into a claim that the complete marketplace is secure.[1]

Evidence and attribution

• Zealynx-authored canonical record: the public report and audit page identify Plakxio as the client, Zealynx as the review provider, the two-day Founder Security Sprint, scope commits, and remediation totals.[1][3]
• Finding-specific evidence: F-2026-0001 documents the authorization mechanism, proof-of-concept sequence, recommendations, resolution, residual configuration limits, and fixed status.[2]
• Attribution class: direct Zealynx engagement. No public evidence identifies a delivery partner.
• Evidence cutoff: the August 31, 2026 report and remediation review at final commit 6478a0273737d9a06b3f1d8b2d811279aaa6ab9f.[1]
• Publication authority: under Zealynx's case-study policy, its public report for Zealynx-delivered work is sufficient authority for this evidence-led technical narrative.
• Limitations: public provider-authored evidence supports technical scope and recorded remediation, but not customer sentiment, business impact, production deployment, or continuing assurance.

Designing gasless NFT settlement?

Zealynx can test whether off-chain orders, privileged operators, holder controls, relayers, and token transfers preserve consent across the full settlement lifecycle. Review the Founder Security Sprint, explore smart contract security audits, or request a scoped marketplace review.

Frequently asked questions

Why did the whitelist bypass ERC-1155 holder consent?

isApprovedForAll returned true for every whitelisted operator against every holder. The class mask restricted token classes, not holder identity or signed intent, and the grant accepted addresses without requiring contract code.[2]

Why was this a system-level issue rather than one incorrect boolean?

The failure connected administrative configuration, the ERC-1155 approval override, class gating, single and batch transfer authorization, and off-chain signature enforcement. The intended settlement contract checked consent, but the badge contract granted authority without enforcing that the operator was a consent-checking mechanism.

How was the finding fixed?

The public resolution records three primary controls: settlement grants require contract code, activation is delayed, and holder opt-outs are enforced by the approval view and both transfer paths. It also records that the proof-of-concept steps were rerun and closed.[2]

Does requiring contract code prove an operator is safe?

No. Code presence excludes a plain EOA but does not prove correct behavior. The delay and holder opt-out provide additional controls, while whitelist administration and the operator implementation remain trusted parts of the design.

Was the fix deployed on Base?

The public evidence verifies remediation against the final reviewed commit; it does not establish production deployment. This case study makes no deployment claim.

Did the sprint prove the marketplace was secure?

No. An audit is point-in-time and scope-limited. The public record documents 16 findings and their recorded statuses, not a guarantee about all code, later changes, deployment configuration, or future behavior.[1]

Sources

[1] https://zealynx.io/audits/plakxio/badge-marketplace-founder-sprint-q3-2026 — Plakxio Founder Security Sprint audit record [2] https://zealynx.io/audits/plakxio/badge-marketplace-founder-sprint-q3-2026/findings/F-2026-0001 — High-severity operator-consent finding and resolution [3] https://raw.githubusercontent.com/ZealynxSecurity/audits/main/web3/2026-08-zealynx-plakxio-founder-sprint.pdf — Canonical public security report