Satori royalties — a 10001 purchase reverts and the NFT stays put

Source & credit. Reproduction of a public audit finding curated by AuditVault — the original finding: 19564-strict-equality-causes-token-purchase-failure-sigmaprime-non. Standalone Foundry PoC and full write-up: 19564-strict-equality-causes-token-purchase-failure-sigmaprime-non_exp in the evm-hack-registry mirror.

Vulnerability classes: vuln/logic/wrong-condition · vuln/arithmetic/rounding · vuln/dos/frozen-funds

Key info#


Protocol	Satori Sports token royalties
Finding	Sigma Prime, AuditVault 19564
Vulnerable code	`TokenRoyaltiesHandler.purchased`
Harm	10001 PAY stays in the handler and token 1 is not delivered
Chain	local synthetic

TL;DR#

purchased splits purchaseCost across royalty receivers with bps * cost / 10000, then requires the sum to equal purchaseCost exactly. Two 5000 bps legs of a 10001 cost each round down to 5000. The sum is 10000, the equality reverts, and the NFT transfer never runs. The 10001 payment remains in the handler. The control uses purchaseCost >= totalPaid, delivers the NFT, and pays 5000 to each receiver, leaving 1 unit of rounding dust.

The vulnerable code#

SOLIDITY

uint256 owed = bps[i] * purchaseCost / 10000;
paid += owed;
royalties.recordRoyalties(entities[i], owed);
// @> VULN: rounded legs sum to 10000, so == 10001 reverts and the NFT is not delivered
require(paid == purchaseCost, "Royalties payment not calculated correctly");

The control replaces the check with require(purchaseCost >= paid).

Root cause#

Integer division rounds each royalty leg down. The legs are not required to sum back to the payment, but the function demands that they do. Any cost that is not a multiple of the basis-point denominator fails the purchase after the payment has already been taken into the handler.

Preconditions#

The royalty configuration is two entities at 5000 bps each. The purchase cost is 10001. The payment sits in the handler and the NFT is still owned by the handler. No special role is required.

Attack walkthrough#

10001 PAY is minted into the handler.
purchased(1, 10001) computes 5000 and 5000.
require(10000 == 10001) reverts.
The NFT owner is still the handler. The caught call leaves the 10001 in place.

Diagrams#

flowchart TD A["Pay 10001 into the handler"] --> B["Two 5000 bps legs each round to 5000"] B --> C["totalPaid is 10000"] C --> D["VULN: 10000 == 10001 reverts"] D --> E["NFT stays with the handler"] E --> F["10001 PAY stays in the handler"]

Impact#

The buyer paid 10001 and does not receive the NFT. Those 10001 units remain in the handler. The same purchase under >= delivers the NFT and pays 5000 to each royalty receiver.

Remediation#

Replace the strict equality with require(purchaseCost >= totalPaid), as the report recommends. Satori fixed the split on commit 923c35b by moving the basis-point division to the UI.

Sources#

Sources & further analysis#

Reproductions & code

Standalone PoC + full trace: 19564-strict-equality-causes-token-purchase-failure-sigmaprime-non_exp (evm-hack-registry mirror).
AuditVault finding: 19564-strict-equality-causes-token-purchase-failure-sigmaprime-non.

Alerts & third-party analyses

Web3Sec X hacked database: search.
Rekt leaderboard: search.
Solodit incident search: search.

These dashboards index community alerts tweets, post-mortems, and independent write-ups. Reach them through the protocol name above to cross-check this reproduction against other analyses.

Source-level debugger — step opcodes and Solidity in sync