Incident Date: 4/27/2026
Resolution Date: 5/20/2026 - Upgrade transaction
TLDR: Your LANDs, Estates, and all assets are safe. The marketplace is fully operational
On April 27, 2026, we received a vulnerability report on Immunefi describing a flaw in EstateRegistry.getFingerprint that allowed an Estate’s contents to be silently swapped while keeping the same on-chain fingerprint. In practice, a seller could list an Estate on the marketplace with a given set of LANDs and, before the buyer’s order executed, substitute a different set of LANDs without invalidating the order’s signature.
Funds: No user funds were lost. The vulnerability required an active marketplace order and a coordinated swap operation; no exploitation has been observed on-chain.
Context
The legacy fingerprint algorithm had a mathematical property that, beyond roughly 256 LANDs, made it possible to swap a subset of LANDs in an Estate for a different subset while keeping the fingerprint unchanged. In practical terms, any Estate larger than ~256 LANDs was at structural risk of an undetectable contents swap. Smaller Estates were far less exposed, but to leave a comfortable safety margin we drew the line much earlier: the patch treats any Estate with 19 or more LANDs as requiring the new fingerprint. For Estates below that threshold, finding a malicious swap is computationally comparable to brute-forcing a private key — essentially impossible with any known technology.
Because the issue stemmed from how the original fingerprint combined LAND identifiers, we determined that a backwards-compatible fix was possible: introduce a new fingerprint algorithm, gate verification behind it, and keep the legacy one available only for the small Estates and time window where it is still safe — avoiding any disruption to Estates already listed on the marketplace.
Remediation
The fix introduces a new getFingerprintV2 function that hashes the Estate contents with keccak256(abi.encode(...)), which is non-linear and bound to the length and order of the LAND array — eliminating the collision class entirely.
The existing getFingerprint function is preserved (now marked UNSAFE in the contract documentation) so read-only integrations continue to work. The on-chain verifyFingerprint function was updated to:
-
Always accept the new v2 fingerprint, regardless of Estate size or time.
-
Accept the legacy v1 fingerprint only as a transitional fallback, and only for Estates with fewer than 19 LANDs and only until 2026-11-26 15:00 UTC.
This dual-mode window gives marketplace integrations a controlled migration path: new orders can be signed with v2 immediately, while orders already signed under v1 remain verifiable until the cutoff. After the cutoff, only v2 is accepted.
The SAB sent the upgrade transaction on May 21, 2026.
Current Status
The patched EstateRegistry implementation has been deployed on Ethereum, and all first-party integrations (dApps, indexers, and signing helpers) have been updated to emit v2 fingerprints by default. The legacy v1 fallback remains active for in-flight orders and will be disabled automatically at the cutoff timestamp on 2026-11-26 15:00 UTC.
Impact on existing orders
Your LANDs, Estates and every assets are safe
-
20 active orders involve Estates with more than 18 LANDs. These cannot be executed against the new contract and must be re-listed by their owners using the updated marketplace flow, which signs against the v2 fingerprint. Affected owners will see a prompt in the marketplace UI guiding them through the re-listing process:
-
Orders covering Estates with fewer than 19 LANDs can still be executed safely. These sit well below the size where the original vulnerability becomes exploitable, and
verifyFingerprintcontinues to accept their existing v1 fingerprints during the transition window. However, this is temporary: on 2026-11-26 15:00 UTC every v1-signed order or rental becomes invalid on-chain, regardless of Estate size. Owners should re-list them under the new flow before the cutoff to avoid losing their listings. -
Rentals are not impacted
-
ThirdParty Marketplaces such as Opensea are not impacted.
Acknowledgment
We thank the whitehat researcher for the responsible disclosure and the constructive collaboration during remediation and research, which allowed us to deploy a backwards-compatible fix with no disruption to active marketplace users.