Skip to content

Latest commit

 

History

History
73 lines (38 loc) · 6.28 KB

2025-02-19.md

File metadata and controls

73 lines (38 loc) · 6.28 KB

Incident Disclosure - 2025-02-19

Summary

0xSplits v2 has announced an issue where USDT cannot be withdrawn from immutable split contracts on mainnet only. This affects the 0xSplit splitter contracts used by all mainnet Art Blocks v3.2 contracts, including all Art Blocks Studio contracts. Their announcement can be found on their public blog here.

At this time, Art Blocks has not observed any damages from this issue; no USDT royalties have been sent to any of the affected splitter contracts.

0xSplits has provided a patched v2.1 version of their contract to address the issue. Art Blocks subsequently deployed a new immutable SplitProviderV0 contract that integrates with the patched 0xSplits v2.1 contract.

For existing contracts, Art Blocks has developed a sequence of actions to be taken by existing core contract admins to migrate to the updated SplitProvider contract. The steps are listed in the Recommended Migration Path section.

Summary of Damages

No damages have been observed at this time.

Background

Art Blocks integrated with 0xSplits v2 in early 2024 while developing the Art Blocks v3.2 contracts. The integration was implemented to achieve compliance with the ERC-2981 NFT Royalty Standard, maximizing the royalty compatibility of future Art Blocks contracts.

Art Blocks did protect against any unforseen issues with the 0xSplits v2 contracts by developing a permissionless SplitProviderV0 contract layer that allows core contract admins to migrate to a new splitter system at their discretion.

Recommended Migration Path

The recommended migration path for core contract admins is as follows:

  1. Inspect your mainnet core contract on etherscan.io. Read function splitProvider() to determine the current address of the splitProvider. If the splitProvider function does not exist, your contract's version is pre-v3.2 and not affected by the 0xSplits V2 issue and no action is required.

  2. If splitProvider() returns address 0x0000000004B100B47f061968a387c82702AFe946, your contract is affected by the 0xSplits V2 issue, and you should proceed to step 3. Otherwise, your contract is not affected by the 0xSplits V2 issue, and no action is required.

  3. Connect your admin wallet to etherscan (via the connect to web3 button). Call the updateSplitProvider() function with the address of the updated Art Blocks SplitProvider contract, 0x000000000ef75C77F6bd0b2Ee166501FbBDb40c8.

    • Note: to find admin wallet, read the admin() function of the core contract to be directed to the adminACL contract, then read the superAdmin() function of the adminACL contract to view the admin wallet.

  4. For each existing project, the admin or artist should call updateProjectArtistAddress, with the existing artist address (to avoid changes). This will trigger a new, patched splitter contract to be assigned to as the recipient of the project's royalties. Note that any new projects added to the core contract will automatically be assigned splitters from the patched splitter contract, resolving all issues going forward.

    • Note: to determine the artist address for each existing project, the core contract's read function projectIdToArtistAddress() may be called on etherscan. additionly, the starting project ID can be found by calling the startingProjectId() function, and the ending project ID can be found by calling the nextProjectId() function and subtracting 1.

  5. For each existing project, you will have a new splitter contract address that is assigned to receive project royalties. The new splitter contract address can be found by reading the projectIdToFinancials(<projectId>) function on etherscan. The last item in the returned array is the splitter contract address. The splitter can be viewed on 0xSplits website.

  6. Notify the Art Blocks team that the migration has been completed.

As is the case with any royalty updates, any previously created orders on some marketplaces may remain stale and could still send royalties to the old splitter contract. However, for new orders, the patched splitter contract will be used. Please notify the Art Blocks team so we can alert third party marketplaces to refresh any cached royalty information.

Details of the Incident

Details of the incident are available in the 0xSplits announcement here. In summary, USDT has a unique approval requirement (beyond the standard ERC-20 specification) that sometimes prevented the 0xSplits V2 system of contracts from withdrawing USDT from the splitter contract.

Details of the Fix

The patched 0xSplits v2.1 contracts resolve the described issue, and Art Blocks has deployed a new SplitProvider contract that integrates with the patched 0xSplits v2.1 contracts, as well as published migration steps for existing core contract admins to migrate to the patched 0xSplits v2.1 contracts.

Additionally, Art Blocks has updated our internal scripts to use the patched 0xSplits v2.1 contracts by default for all new core contract deployments.

Timeline of Events

2025-02-12: 0xSplits published blog post warning of the issue.

2025-02-13: Art Blocks became aware of the blog post, and began development of a patch and migration steps for existing core contract admins.

2025-02-18: Art Blocks review of the described mitigation process (internally and with 0xSplits) to ensure it is safe and effective.

2025-02-19: Art Blocks published this disclosure; broader communication plan begins.

ongoing: Art Blocks continues monitoring affected contracts to ensure migration steps are completed.

References