The contract inherits from ERC1155Holder, which only implements the ERC1155Receiver interface (0x0e89341c), allowing the contract to receive ERC1155 tokens. However, the contract does not implement the full ERC1155 interface (0xd9b67a26), which would allow it to manage and transfer ERC1155 tokens. As a result, supportsInterface returns false for 0xd9b67a26, despite the potential expectation that the contract fully supports ERC1155 tokens
Internal pre-conditions
The contract implements ERC1155Receiver (interface ID 0x0e89341c), allowing it to safely receive ERC1155 tokens.
ERC1155 core functionality is not implemented.
The contract does not implement the core ERC1155 interface (0xd9b67a26), meaning it cannot fully manage or transfer ERC1155 tokens
External pre-conditions
No response
Attack Path
The external contract may continue assuming that ERC1155 support exists. This could lead to further misuse of the contract, potential integration bugs, or failed transactions.
Impact
Integrators might expect full ERC1155 support but find that the contract cannot manage or transfer tokens. This can cause failed transactions or unexpected behavior, especially when interacting with systems that rely on the full ERC1155 interface.
PoC
function test_interface() public {
// assertFalse(edition.supportsInterface(bytes4(0xd9b67a26)));
assertFalse(edition.supportsInterface(bytes4(0x0e89341c)));
}
Mitigation
function supportsInterface(bytes4 interfaceId)
public
view
override(IEdition, ERC1155, ERC2981)
returns (bool)
{
Waydou
Medium
`PredictDotLoan.supportsInterfaceis not EIP1155 compliantSummary
According to the ERC-1155 specification](https://eips.ethereum.org/EIPS/eip-1155#specification), the smart contracts that are implementing it MUST have a supportsInferface(bytes4) function that returns true for values 0xd9b67a26 and 0x0e89341c. The current implementation of [PredictDotLoan.sol]https://github.com/sherlock-audit/2024-09-predict-fun/blob/41e70f9eed3f00dd29aba4038544150f5b35dccb/predict-dot-loan/contracts/PredictDotLoan.sol#L844C14-L844C31 will return false for 0x0e89341c . Same issue can be found here https://solodit.xyz/issues/m-13-editionsupportsinterface-is-not-eip1155-compliant-sherlock-titles-publishing-protocol-git
Root Cause
The contract inherits from ERC1155Holder, which only implements the ERC1155Receiver interface (0x0e89341c), allowing the contract to receive ERC1155 tokens. However, the contract does not implement the full ERC1155 interface (0xd9b67a26), which would allow it to manage and transfer ERC1155 tokens. As a result, supportsInterface returns false for 0xd9b67a26, despite the potential expectation that the contract fully supports ERC1155 tokens
Internal pre-conditions
The contract implements ERC1155Receiver (interface ID 0x0e89341c), allowing it to safely receive ERC1155 tokens. ERC1155 core functionality is not implemented.
The contract does not implement the core ERC1155 interface (0xd9b67a26), meaning it cannot fully manage or transfer ERC1155 tokens
External pre-conditions
No response
Attack Path
The external contract may continue assuming that ERC1155 support exists. This could lead to further misuse of the contract, potential integration bugs, or failed transactions.
Impact
Integrators might expect full ERC1155 support but find that the contract cannot manage or transfer tokens. This can cause failed transactions or unexpected behavior, especially when interacting with systems that rely on the full ERC1155 interface.
PoC
function test_interface() public { // assertFalse(edition.supportsInterface(bytes4(0xd9b67a26))); assertFalse(edition.supportsInterface(bytes4(0x0e89341c))); }
Mitigation
function supportsInterface(bytes4 interfaceId) public view override(IEdition, ERC1155, ERC2981) returns (bool) {