# Centralisation RIsk: Owner Of RoyaltyVault Can Take All Funds

RoyaltyVault owner can set platformFee to 100%, diverting all current and future balances to the owner-controlled recipient and blocking sendToSplitter.

- Payout: Audit contest
- Severity: high
- Program: Joyn
- Found by: kirk-baird
- Disclosed: 2022-07-25
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-03-joyn-findings/issues/9
- Library page: https://bugbountylibrary.com/r/c4%3A2022-03-joyn%3AH-05
- Tags: domain:web3 impact:dos impact:funds-loss kind:contest platform:code4rena sev:high tech:solidity technique:source-review vuln:access-control vuln:business-logic vuln:dos

**Target:** RoyaltyVault royalty splitter contract
**Root cause:** setPlatformFee has onlyOwner and no upper bound, so the owner can set platformFee to 10000 (100%), routing the entire balance and future royalties to platformFeeRecipient instead of the splitter.
**Steps:**
1. Owner calls `setPlatformFee(10000)` on RoyaltyVault (onlyOwner, no max check).
2. platformFee becomes 100%, so platformShare equals the full balance and splitterShare becomes 0.
3. Subsequent `sendToSplitter()` calls send all funds to platformFeeRecipient (owner-controlled) or revert, blocking NFT transfers that hook royalty payment.
**How found:** Code review of the onlyOwner setPlatformFee setter noting the absence of a maximum bound and its effect on the splitter share computation.
**Exploitation:** Malicious or compromised owner sets platformFee to 10000; all vault balance and future royalties flow to the owner-controlled platformFeeRecipient, and sendToSplitter failing can hold NFT transfers hostage.
**Escalation:** High fee can also DOS sendToSplitter, preventing all NFT transfers that call it atomically on transfer.
**Insight:** On royalty/splitter contracts, audit owner-only fee/config setters for missing upper bounds and check whether a maxed fee makes the splitter share zero or reverts, turning fund theft into a transfer-blocking DOS.