Deployed contracts' addresses for all supported networks can be found here
Consists of:
- Exchange v2: responsible for sales, auctions etc.
- security audit was done by ChainSecurity: https://chainsecurity.com/security-audit/rarible-exchange-v2-smart-contracts/
- Tokens: for storing information about NFTs
- Specifications for on-chain royalties supported by Rarible
See more information about Rarible Protocol at docs.rarible.org.
Also, you can find Rarible Smart Contracts deployed instances across Mainnet, Testnet and Development at Contract Addresses page.
yarn
yarn bootstrap
if error, check node version for yarn
expected node version ">=14.18.2", for check and set necessary version use, for example
node -v
nvm use 18.13.0
then use truffle to compile, test: cd into directory and then
truffle test --compile-all
Rarible protocol is a combination of smart-contracts for exchanging tokens, tokens themselves, APIs for order creation, discovery, standards used in smart contracts.
The Protocol is primarily targeted to NFTs, but it's not limited to NFTs only. Any asset on EVM blockchain can be traded on Rarible.
Smart contracts are constructed in the way to be upgradeable, orders have versioning information, so new fields can be added if needed in the future.
Users should do these steps to successfully trade on Rarible:
- Approve transfers for their assets to Exchange contracts (e.g.: call approveForAll for ERC-721, approve for ERC-20) — amount of money needed for trade is price + fee on top of that. Learn more at exchange contracts README.
- Sign trading order via preferred wallet (order is like a statement "I would like to sell my precious crypto kitty for 10 ETH").
- Save this order and signature to the database using Rarible protocol API (in the future, storing orders on-chain will be supported too).
If the user wants to cancel the order, he must call cancel function of the Exchange smart contract.
Users who want to purchase something on Rarible should do the following:
- Find an asset they like with an open order.
- Approve transfers the same way (if not buying using Ether).
- Form order in the other direction (statement like "I would like to buy precious crypto kitty for 10 ETH").
- Call Exchange.matchOrders with two orders and first order signature.
You are welcome to suggest features and report bugs found!
The codebase is maintained using the "contributor workflow" where everyone without exception contributes patch proposals using "pull requests" (PRs). This facilitates social contribution, easy testing, and peer review.
See more information on CONTRIBUTING.md.
-
main
This is the default branch where the latest development happens once releases are completed and merged back in. -
release/*
Used for stabilizing and releasing code. A newrelease/x
branch is created frommain
when the team is ready to prepare a new release. -
feature/PT-xxx
Short-lived feature branches for implementing new features or bug fixes. Merged into arelease/*
branch when preparing a release.
-
Create a Release Branch
- When ready to release, create a new
release/*
branch frommaster
.
- When ready to release, create a new
-
Merge Feature Branches
- Merge all relevant
feature/PT-xxx
branches into the newrelease/*
branch.
- Merge all relevant
-
Tag & Deploy (Beta)
- In the
release/*
branch, create a beta tag using the formatv{major}.{minor}.{patch}-beta.{number}
. - Deploy npm packages by running:
npx lerna version v{major}.{minor}.{patch}-beta.{number} --yes
- In the
-
Test on Testnet
- Deploy from the
release/*
branch to the testnet for validation and QA.
- Deploy from the
-
Deploy to Mainnet
- Once testing is complete and everything looks good, deploy the same
release/*
branch to mainnet.
- Once testing is complete and everything looks good, deploy the same
-
Merge Back to
master
- After a successful release, merge the
release/*
branch back intomaster
.
- After a successful release, merge the
- The versions of Cargo packages and npm packages are synced.
- If you need to fix only the npm package, you can simply bump the patch version (e.g., from
v1.2.3-beta.1
tov1.2.4-beta.1
).
flowchart LR
A["feature/PT-xxx"] --> B["release/*"]
B --> C["Create Release Branch from master"]
C --> D["Tag: v{major}.{minor}.{patch}-beta.{number}"]
D --> E["Deploy to Testnet"]
E --> F["Test & Validate"]
F --> G["Deploy to Mainnet"]
G --> H["Merge release/* back to master"]
Go to the Rarible Jenkins Protocol Contracts and check the release status.
Smart contracts for Rarible protocol are available under the MIT License.