Skip to main content
• 5 min read

Royal Royalties Exploit: $261K
Drained via Pro-Rata Accounting Logic Flaw

$261K in USDC was drained from Royal's Royalties contract on Polygon after a pro-rata accounting flaw let an attacker inflate LDA tier ownership.

AUTOSEC.DEVAUTOSEC.DEV
Royal Royalties Exploit: $261K Drained via Pro-Rata Accounting Logic Flaw
  • Incident Date: June 23, 2026
  • Target: Royal Royalties contract
  • Target Overview: Royal is a music-rights platform that sells limited digital assets (LDAs), giving holders access to artist-related rights and benefits. The reported exploit affected an older Royalties contract on Polygon, not a newly disclosed broader platform compromise.
  • Total Loss: Approximately $261,000 USDC
  • Reported Attacker Address: 0xbd829aa63311bb1e3c0ea58a7193364de670bd56
  • Reported Victim Contract: 0xfe16ee78828672e86cf8e42d8a5119ab79877ec7
  • Attack Vector: Smart-contract logic flaw / pro-rata royalty accounting bug / flash-loan assisted exploitation

Incident Review & Technical Details​

1. Attack Path​

  1. The attacker targeted an older Polygon royalties contract: TenArmor reported a suspicious attack involving an old Royalties contract on Polygon. Defimon identified the affected system as Royal's Royalties contract and linked the same exploit transaction.
  2. A flash loan amplified the attack setup: According to Defimon, the attacker flash-loaned USDC and obtained an outsized tier-42 LDA balance on a freshly created contract. That position reportedly made the attacker appear to control roughly 100x the intended pro-rata ownership.
  3. A small royalty deposit created an oversized claim path: The attacker deposited roughly 2,638 USDC of royalties through deposit(). The contract's accounting then treated the inflated tier balance as the basis for royalty distribution.
  4. claim() overpaid the attacker: Defimon reported that claim() paid out roughly 263,808 USDC, about 100x the deposit. The suspected failure point was _settleUcr(), which scaled rewards by tierBalanceOf / supply without effectively bounding ownership to 100%.
  5. The attacker repaid the flash loan and retained the spread: After the inflated claim, the attacker repaid the flash loan and kept approximately $261,000 USDC in net value from the victim proxy.

2. Impact Scope​

  • Protocol-Level Loss: The reported net loss was approximately $261,000 USDC from the Royal Royalties contract on Polygon.
  • Affected Asset: USDC on Polygon.
  • Affected Component: The affected surface was described as an old Royalties contract and the victim proxy at 0xfe16...7ec7.
  • Attack Dependency: The exploit appears to have required a flash-loan-assisted setup plus an inflated LDA tier balance, but the underlying root cause was the contract's pro-rata royalty accounting.
  • Ecosystem Contagion: No liquidation cascade, stablecoin depeg, partner-protocol bad debt, or cross-chain contagion was reported in the reviewed sources.
  • Disclosure Gap: No official Royal postmortem, patch note, user-impact statement, or fund-recovery update was identified in the reviewed sources at the time of writing.

3. Official Statements​

  • Royal: No official Royal statement or final postmortem was identified in the reviewed sources at the time of writing.
  • TenArmor: TenArmor reported that its monitoring system detected a suspicious attack involving an old Royalties contract on Polygon, with the loss estimated at roughly $261,000.
  • Defimon Alerts: Defimon attributed the loss to a logic error in pro-rata royalty accounting and described the exploit flow involving a flash loan, an inflated tier-42 LDA balance, deposit(), claim(), and the _settleUcr() reward-scaling path.

4. Investigation Progress​

The immediate technical question is whether the same accounting assumption exists in any other Royal royalty-distribution contracts, tiers, or proxy deployments. The failure mode is compact but dangerous: a reward formula that trusts token or tier balances as a pro-rata ownership signal can become value-amplifying when supply, balance, or tier membership can be shaped by an attacker-controlled contract.

Recommended response steps for Royal-style royalty distribution systems:

  • Reconstruct the exploit transaction on a Polygon fork and convert the failing deposit() / claim() path into regression tests.
  • Review every royalty calculation that depends on tierBalanceOf, tier supply, LDA balances, delegated ownership, or proxy-created contracts.
  • Add hard caps so a claimant's computed ownership share cannot exceed 100% of the intended distribution base.
  • Check whether the same _settleUcr() logic, or equivalent pro-rata math, exists in other royalty pools, tiers, or historical contract deployments.
  • Publish the affected contract list, exploit transaction, patched invariant, current fund status, and any user remediation process.

AUTOSEC.DEV Solution​

The Royal incident shows why pro-rata reward systems need invariant testing around ownership, supply, and claimable value, especially when flash loans can reshape state inside one transaction.

  1. Secure Code Review - The reported Royal exploit centered on _settleUcr() scaling rewards by tier balance over supply without preventing an ownership share above 100%. AUTOSEC.DEV reviews DeFi and royalty-distribution contracts for arithmetic invariants, balance-to-supply assumptions, proxy edge cases, and claim paths where a small deposit can unlock a disproportionate payout.
  2. Penetration Testing - The attacker reportedly combined a flash loan, a freshly created contract, and a tier-42 LDA balance to turn deposit() into an oversized claim(). We reproduce adversarial workflows on forks, including flash-loan state shaping, synthetic holder positions, abnormal pro-rata ownership, and repeated claim attempts before mainnet exposure.
  3. Incident Response - For recent Polygon drains like this one, AUTOSEC.DEV can support exploit reconstruction, affected-contract scoping, fund-flow tracing, freeze-request evidence packages, disclosure support, and regression-test design after the vulnerable formula is patched.

Reference​