I know the Typescript SDK is the preferred route to all things Rarible Protocol, but I did have a need to play with the Rarible contracts directly and I had tried to use brownie to do that. I quickly ran into issues, so opened a ticket for the team to consider packaging the contracts in a brownie friendly format. Right now the rarible protocols-contracts repo doesn't even have a release yet, so I can't even try to import it.

For a well documented example see the work by the Chainlink team and Patrick Collins show how to make NFTs while also showing how to use the Chainlink products. I think a Rarible equivalent of say an OpenZeppelin NFT with the Rarible Royalties would be a great demo (something I was trying to do.) The more "features" you can sell that the protocol supports, the more folks that may go all in on the Rarible Protocol.

• https://github.com/smartcontractkit/chainlink-mix
• https://www.youtube.com/watch?v=p36tXHX1JD8&ab_channel=PatrickCollins
• https://github.com/eth-brownie/brownie

I would see this as helpful for future Hackathons etc as you can get some Python developers playing with the Rarible Protocol.

When using truffle commands, including the ones in the ReadMe, all that is returned is " Could not find suitable configuration file". This is because the Readme doesn't mention the commands needed like truffle init. This should be updated in order to help those who aren't super devs and don't find the commands on their own.

I think https://github.com/rarible/protocol-contracts/blob/master/royalties/contracts/impl/AbstractRoyalties.sol#L26 should be payable

royalties[_id][i].account = payable(address(uint160(_to)));

instead of

royalties[_id][i].account = address(uint160(_to));

As you can see in LibPart.

    struct Part {
        address payable account;
        uint96 value;
    }

In the OrderValidator.validate() function, I think the order will always be considered valid if the order.maker is set to 0 and the signature is empty.

Because signer remains 0 if the signature is empty and then the check

if  (signer != order.maker)

will be

if (0 != 0)

which will skip the body of the if, and the validate() function won't fail.

Maybe this isn't really an issue because the transaction will fail at some point later anyway, but it's probably safer to
require (order.maker != address(0))

Run:
cd tokens/
truffle test
Detect errors

1. Contract: ERC1155Rarible
   mint and transfer by minter, token create by Factory:
   Error: Invalid number of parameters for "undefined". Got 1 expected 3!
   at Context. (test/erc-1155/ERC1155Rarible.test.js:29:39)
   at runMicrotasks ()
   at processTicksAndRejections (internal/process/task_queues.js:97:5)

2. Contract: ERC721Rarible
   mint and transfer by minter, and token created by ERC721Factory :
   Error: Invalid number of parameters for "undefined". Got 1 expected 3!
   at Context. (test/erc-721/Rarible.test.js:36:38)
   at runMicrotasks ()
   at processTicksAndRejections (internal/process/task_queues.js:97:5)

Hi, is there any uml diagram where you can see the architecture and relationships between contracts?

thanks

What is the purpose of this function?

thank you

function _updateAccount(uint256 _id, address _from, address _to) internal {
        uint length = royalties[_id].length;
        for(uint i = 0; i < length; i++) {
            if (royalties[_id][i].account == _from) {
                royalties[_id][i].account = payable(address(uint160(_to)));
            }
        }
    }

Would you create a develop branch for any other contributors?

Directly Merging codes to master is dangerous.

I think this strategy is good enough to apply
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

Hello,

It's pixa.pics, our repository https://github.com/pixa-pics/pixa-pics.github.io is the source code of our software seeking funds and enabling people to upscale pixel art that can be generated from images such as selfies which by then after editing, works to weight 10-20Kb in optimized lossless PNG which can be stored inside smart contract in base 64 data url, it's simple, we can provide our code to upscale images "on-the-fly" inside the web UI, and users can use our app which can get sponsored to produce images that can be sold on your platform, a few lines of code are required to be developed.

Within 8.2Kb!

I have a question / issue regarding your order validator service:
https://github.com/rarible/ethereum-indexer-public/blob/8061d075baf19ea6bb59fe56820fa8a96cd21a65/order/api/src/main/kotlin/com/rarible/protocol/order/api/service/order/validation/validators/OrderSignatureValidator.kt#L49

Your logic for validating signature is based on ERC-1271. Any chance you could upgrade it to ERC-6492?

Example implementation
https://github.com/AmbireTech/signature-validator

That's a serious business blocker for us as we're implementing accounts as per new ERC-4337. Signer becomes a separate entity and it's not the same as NFT owner / order maker.

All but sell SDK operations (mintAndTransfer, directPurchase, safeTransfer, burn, cancel) are happening in the background via direct eth_sendTransaction calls. The sell happens differently: eth_signTypedData_v4 and then api/orders. We were able to upgrade all eth_sendTransaction logic without any changes on your end but the flow of sell logic makes it harder / impossible for us.

Eventully as a plan b - do we have any way to list NFT for sale without using your API / indexer?

Hey guys!
Firstly, you're creating amazing job! I'm currently writing rarible tutorials and was wondering is it possible to create an auction using Rarible protocol? If so where I can find the contract?

Thanks for help!
Szymon

hello!
there is no such diagram yet, but we are planning to make it soon.
gonna post it here when it's done

#150

TokenName: KuCoin Token
ChainName: KCC

Symbol: KCS
Documentation: https://docs.kcc.io/
Reason: KCC is a high-performance and decentralized public chain built by KCS’ and KuCoin’s fan communities.
Developed based on go-there with the purpose of providing community users with a higher-speed, convenient and low-cost blockchain user experience.

Fully compatible with Ethereum and ERC-20 smart contracts, extremely low costs in migration.

Hello,

I am trying to implement the rarible royalties interface for my ERC720 and ERC1155 tokens, but I wasn't sure if my contract would be able to call the rarible contracts if I deployed to the polygon main-net, does the rarible royalties contracts support polygon chain ?

Thank you

Rarible has an extensible DEX which allows for custom asset matcher implementations.

In order to add the ability for Rarible DEX to allow for matching bundles of assets that can be used for p2p trades, I propose below shown BundleAssetMatcher.sol

// SPDX-License-Identifier: MIT

pragma solidity 0.7.6;
pragma abicoder v2;

import "@rarible/lib-asset/contracts/LibAsset.sol";

contract BundleAssetMatcher {

    bytes4 constant public BUNDLE_ASSET_CLASS = bytes4(keccak256("BUNDLE"));    

    function matchAssets(LibAsset.AssetType memory leftAssetType, LibAsset.AssetType memory rightAssetType) internal view returns (LibAsset.AssetType memory) {
        bytes4 classLeft = leftAssetType.assetClass;
        bytes4 classRight = rightAssetType.assetClass;
        
        if (classLeft == BUNDLE_ASSET_CLASS) {
            if (classRight == BUNDLE_ASSET_CLASS) {
                bytes32 leftHash = keccak256(leftAssetType.data);
                bytes32 rightHash = keccak256(rightAssetType.data);
                if (leftHash == rightHash) {
                    return leftAssetType;
                }
                return LibAsset.AssetType(0, EMPTY);
            }
        }
    }
}

This simple AssetMatcher implementation can be deployed and registered as a matcher in the matchers mapping of the AssetMatcher contract.

Below is an accompanying BundleTransferProxy. There are ways to make this proxy more efficient by using safeBatchTransferFrom in the case of ERC1155 assets and packing arrays of asset details in the structs. But I have tried to keep this proxy as simple as possible.

This BundleTransferProxy has to be registered in the proxies array with the bytes4 key as bytes4(keccak256("BUNDLE")) in the TransferExecutor contract. Also, we would need to call the addOperator method on BundleTransferProxy so set Rarible contract(s) an operator.

// SPDX-License-Identifier: MIT

pragma solidity >=0.6.9 <0.8.0;

import "../roles/OperatorRole.sol";
import "@rarible/exchange-interfaces/contracts/ITransferProxy.sol";
import "@openzeppelin/contracts-upgradeable/token/ERC20/IERC20Upgradeable.sol";
import "@openzeppelin/contracts-upgradeable/token/ERC721/IERC721Upgradeable.sol";
import "@openzeppelin/contracts-upgradeable/token/ERC1155/IERC1155Upgradeable.sol";

contract BundleTransferProxy is ITransferProxy, Initializable, OperatorRole {

    struct ERC20Details {
        IERC20Upgradeable token;
        uint256 amount;
    }

    struct ERC721Details {
        IERC721Upgradeable token;
        uint256[] id;
    }

    struct ERC1155Details {
        IERC1155Upgradeable token;
        uint256 id;
        uint256 amount;
        bytes calldata data;
    }

    function __ERC20TransferProxy_init() external initializer {
        __Ownable_init();
    }

    function transfer(LibAsset.Asset calldata asset, address from, address to) external onlyOperator {
        // unpack the asset data
        ERC20Details[] memory erc20Details;
        ERC721Details[] memory erc721Details;
        ERC1155Details[] memory erc1155Details;

        (erc20Details, erc721Details, erc1155Details) = abi.decode(
            asset.assetType.data,
            (ERC20Details[], ERC721Details[], ERC1155Details[])
        );

        // transfer ERC20 assets
        for (uint256 i = 0; i < erc20Details.length; i++) {
            require(
                erc20Details[i].token.transferFrom(from, to, erc20Details[i].amount), 
                "failure while transferring"
            );
        }

        // transfer ERC721 assets
        for (uint256 i = 0; i < erc721Details.length; i++) {
            erc721Details[i].token.safeTransferFrom(from, to, erc721Details[i].id);
        }

        // transfer ERC1155 assets
        for (uint256 i = 0; i < erc1155Details.length; i++) {
            erc1155Details[i].token.safeTransferFrom(from, to, erc1155Details[i].id, erc1155Details[i].amount, erc1155Details[i].data);
        }
    }
}

A field creators in ERC1155Lazy is public. However, ERC721Lazy declares this field private. I couldn't find any other reason why this field is declared as public so I believe this field should be private. Is there any reason this field doesn't match with ERC721Lazy?

When I'm referring to contract owner I mean an owner in the meaning of @openzeppelin/contracts-upgradeable/access/OwnableUpgradeable

For setting up royalties on an external collection a user can call RoyaltiesRegistry.setRoyaltiesByToken
For the call to succeed caller has to be either owner of RoyaltiesRegistry contract or owner of the token contract.

Protocol contracts allow to call those functions multiple times, which means that token contract owner can change royalties in between exchange sales, potentially setting royalties up to 99.99%.

I see you used ECDSA.recover() to validate EOA signature:

Your fallback logic is to validate if signature is smart-contract based (according to EIP1271). But recover() method will revert in case of invalid signature (see LibSignature.sol, potentially copied from OZ: ECDSAUpgradeable.sol#v3.4.0). You have to switch to newer version to be able validate signature without internal revert in library (upcoming 4.3.0 release branch: ECDSAUpgradeable.sol#release-v4.3). Moreover I suggest you to check this new library to validate both EOA and SC based signatures: SignatureCheckerUpgradeable.sol.

hello,

Most of the test examples on royalties show how to save, modify and get the royalties associated with the token.
ie. the royalties are being saved or updated and then using get royalties e.x. royaltiesRegistryTest._getRoyalties(), you get the royalties associated with the token ID.

However, there is no example in any of the royalty folders that shows "when does the Artist actually receive the royalty amount after the successful transfer of token from owner A to B" (say ERC721 transfer, after calling, safeTransferFrom(A, B, token ID)).

Which function in the rarible royalty protocol is responsible to pay the royalty amount to the artist or how is it handled in rarible is not tested.

Thanks.!

Hello, please assign a license to these contracts, i.e. are we free to modify them and deploy our own?

Pixelarts_NFTs_PixaPics_Light.pdf

No, really!?, here you'll find additional information, thanks in advance to developers for forwarding this issue that asks if by anyway, anyone is interested in 1:1 stored blockchain images or not, as a functionality to add into some SDKs anyway.

Hi, I have previously asked if there was any architecture diagram to understand how the contracts work as a whole and I have been told that there is no such diagram.

Looking at the directions of deployment in the different networks.
In Polygon for example there are these 4 contracts deployed:

Now at Testnet (Rinkeby, Mumbai) these contracts are deployed:

Why has this been done? What are Asset Contract ERC-721 and Asset Contract ERC-1155 for? At least in Polygon they are not verified.

In testnet there is this contract NFT Transfer Proxy (for Approvals) while in Polygon it is specified as Transfer Proxies. What is the difference?

thanks

I am the creator and owner of the NFTS CryptoNicholas collection, and I use the safepall wallet, for several days now, my collection has disappeared from the wallet, when I contacted the wallet support, I found out that the problem is not validating the source code that is in rarible after nft minting failed pls check my problem ،And confirm my source code؛thanks
Address conteract collection:
https://rarible.com/collection/polygon/0x93e992922fbb0212cf4e1c941e284fd2eae3ca05/items
The link that SFP wallet support sent to investigate the cause of the problem:
https://gopluslabs.io/nft-security-detection/137/0x93e992922fbb0212cf4e1c941e284fd2eae3ca05

Hi, I created a simple contract that inherits from ERC1155Rarible. I'm using hardhat to create tests for it. When my test deploys the contract to the HRE (Hardhat Runtime Environment), I get this error:

Error: cannot estimate gas; transaction may fail or may require manual gas limit [ See: https://links.ethers.org/v5-errors-UNPREDICTABLE_GAS_LIMIT ] (reason="Transaction reverted: trying to deploy a contract whose code is too large", method="estimateGas", transaction={"from":"0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266","data":"0x6...","accessList":null}, error={"stackTrace":[{"type":21,"sourceReference":{"sourceName":"contracts/MyNftUpgradeable.sol","sourceContent":"// SPDX-License-Identifier: MIT\r\npragma solidity ^0.7.6;\r\npragma abicoder v2;\r\n\r\n// import \"@openzeppelin/contracts/token/ERC721/extensions/ERC721Enumerable.sol\";\r\n//Ownable is needed to setup sales royalties on Open Sea\r\n//if you are the owner of the contract you can configure sales Royalties in the Open Sea website\r\n// import \"@openzeppelin/contracts/access/Ownable.sol\";\r\n//the rarible dependency files are needed to setup sales royalties on Rarible\r\n// import \"rarible/royalties/contracts/impl/RoyaltiesV2Impl.sol\";\r\nimport \"@rarible/tokens/contracts/erc-1155/ERC1155Rarible.sol\";\r\n\r\ncontract MyNftUpgradeable is ERC1155Rarible {\r\n    \r\n}\r\n","contract":"MyNftUpgradeable","function":"constructor","line":13,"range":[590,651]}}],"data":"0x"}, code=UNPREDICTABLE_GAS_LIMIT, version=providers/5.6.8)
      at Logger.makeError (node_modules\@ethersproject\logger\src.ts\index.ts:261:28)
      at Logger.throwError (node_modules\@ethersproject\logger\src.ts\index.ts:273:20)
      at checkError (node_modules\@ethersproject\providers\src.ts\json-rpc-provider.ts:78:20)
      at EthersProviderWrapper.<anonymous> (node_modules\@ethersproject\providers\src.ts\json-rpc-provider.ts:603:20)
      at step (node_modules\@ethersproject\providers\lib\json-rpc-provider.js:48:23)
      at Object.throw (node_modules\@ethersproject\providers\lib\json-rpc-provider.js:29:53)
      at rejected (node_modules\@ethersproject\providers\lib\json-rpc-provider.js:21:65)

This is my contract:

// SPDX-License-Identifier: MIT
pragma solidity ^0.7.6;
pragma abicoder v2;

import "@rarible/tokens/contracts/erc-1155/ERC1155Rarible.sol";

contract MyNftUpgradeable is ERC1155Rarible {
    
}

Judging from the stack trace, it doesn't seem to be a hardhat error. Since this contract is already deployed on mainnet, I think it's probably a configuration error. Any tips?

How do you add custom fees