1 unstable release
0.1.0 | May 29, 2023 |
---|
#15 in #producer
95KB
1.5K
SLoC
Droplinked contract
You can download the droplinked little contract testing environment here
Rust docs of source code could be found here
Contract Interface documentation could be found here
Build and deploy
Prerequisites
You need to have CLI Client
, rust
(1.60.0-nightly or higher), and make
installed in your system.
Build
Run :
make build-contract
in the ndpc_contract folder, in order to build the WASM file, to deploy it into casper chain.
The result of this build would be located in ndpc_contract/deploy/contract.wasm file.
If you do not have make
installed, you could run this command directly:
cd contract && cargo build --release --target wasm32-unknown-unknown
wasm-strip contract/target/wasm32-unknown-unknown/release/contract.wasm 2>/dev/null | true
cp contract/target/wasm32-unknown-unknown/release/contract.wasm deploy/contract.wasm
Docs
Run :
make doc
in the ndpc_contract folder, in order to make the rust documentations of the contract
Deploy
In deploy part, we should send this WASM file, to casper nodes, to deploy them on the chain, Run :
casper-client put-deploy -n http://CSPR_RPC:7777 \
--chain-name CHAINNAME --payment-amount 231420060000 \
-k PATH_TO_SECRET_KEY --session-path deploy/contract.wasm \
--session-arg "ratio_verifier:string='PUBLICKEY_OF_RATIO_VERIFIER'" \
--session-arg "fee:u64='FEE'" \
--ttl "5hour"
where:
CSPR_RPC
is the ip address of a casper rpc node (for testnet or mainnet) which could be found here and here for testnet or mainnet nodes,CHAINNAME
should becasper-test
for testnet, andcasper
for mainnet.PATH_TO_SECRET_KEY
, which could be accessed by downloading your private-key fromcasper-signer
FEE
which should be set to the current UNIXEPOCH time, it is used for security issues on contractPUBLICKEY_OF_RATIO_VERIFIER
, should be set to the public key of the party (or person), who signs the CSPR/USDT ratio forbuy
entrypoint
Unit and Integration tests
To run the tests, cd into the ndpc_contract folder, and in a linux environment with make installed, run :
make test
You should see the following result in your terminal :
running 16 tests
test tests::install_contract_with_error ... ok
test tests::install_contract_test ... ok
test tests::mint_entrypoint ... ok
test tests::approve_entry_point_with_error ... ok
test tests::cancel_request_entry_point_with_auth_error ... ok
test tests::approve_entry_point_with_auth_error ... ok
test tests::cancel_request_entry_point_with_error ... ok
test tests::approve_entry_point ... ok
test tests::cancel_request_entry_point ... ok
test tests::disapprove_entry_point_auth_error ... ok
test tests::disapprove_entry_point ... ok
test tests::disapprove_entry_point_error_amount ... ok
test tests::disapprove_entry_point_error_approved_id ... ok
test tests::mint_product_with_error ... ok
test tests::publish_request_with_error ... ok
test tests::publish_request_entry_point ... ok
test result: ok. 16 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 4.32s
Also you can change the code in tests/src dir, and add your tests, or edit this tests. Currently there is a test method, for each entrypoint of contract (except buy method which needs a more complex testing), which are : Mint
, Publish_request
, approve
, cancel_request
, disapprove
Introduction
On the droplinked protocol, we are registering products on chain and to enable 3rd party publishers to leverage these registered products and sell them across any marketplace, dapp or native site in order to earn commission. We are complimenting this with headless tooling for NFT Gated store fronts on droplinked.com and other valued added NFT solutions. This particular repository contains the customized contract for the Casper Network.
droplinked.com needs to interact with the casper-signer in order to sign transactions. Interaction with the casper-signer is nessesary for login, minting, buying, publishing and all other actions that require a signature.
droplinkeds' contract implements base functionalities of ethereum's ERC-1155 standard. This contract implements SFT tokens (Semi-Fungible Token), which have both uniqueness and value. For example, a producer wants to mint 1M NFTs of the same product (each product has an nft which describes who owns the item); by minting 1M NFT's in a standard such as an ERC-721 (CEP47) is not cost effective (storing 1M ID's and owner address will cost a lot of gas); so instead of minting them one by one, we mint a base token (which contains the ID), and hold that id alongside the number of tokens that a particular account owns.
This way, we only store a single token ID (which represents the product), and a single number (which represents how many of these token ID's a person owns) for each particular account.
On droplinked, a publisher can send a publish request to the producer with a particular pre-defined commission amount. The producer can accept or reject requests and if a request is accepted, the publisher is then given the abilkity to publish the product to share with consumers and earn their entitled settlement portion.
There exists a python util file which interacts with the contract (for testing purposes). It uses 3 accounts (their keys are located in the Keys Directory).
Structure of the contract
Here we explain each structure used within the contract and how they are used:
- NFTHolder : this struct holds the token ID and its amount for a specific account. remaining_amount is the amount left which is not published for a publisher.
- NFTMetadata : this struct holds the metadata of a token. It has a name, a URI(it can be IPFS hash), and a checksum (the hash of the file uploaded off-chain), and a price (in USD). We will add functionality to buy method to buy a token with a constant USD price that levarage CSPR token in future.
- PublishRequest : this struct holds the request of a publisher to a producer to publish a token. It has a holder_id, amount, a publisher address, a producer address, and offer_id. this struct will be saved in a dictionary which maps a request_id to a PublishRequest.
- ApprovedNFT : this struct holds the data of the approved tokens (for publishers), it has a holder_id, amount, owner and publisher account address, the token_id, and the amount of commission. After approving a PublishRequest by a producer, it will be saved in a dictionary which maps every approved_id to this object.
- PublishOffer : this struct holds the token details and commission that the producer declared for it's NFTs, an offer_id will be mapped into this struct in
offers
dict.
Methods (EntryPoints)
Here we explain each method within the contract and how they are used:
- Mint : gets (
metadata
,price
,amount
,reciver_key
) and mints theamount
of tokens toreciver_key
's account. It first stores the metadata in aNFTMetadata
struct and saves it inmetadas
dict (which maps a token_id to itsNFTMetadata
). if themetadata
is already minted, it will use its existingtoken_id
. then it will create aNFTHolder
struct and save it inholders
dict (which maps a holder_id to a list ofNFTHolder
structs). If thereciver_key
already owns this token, it will add theamount
to itsNFTHolder
struct, otherwise it will create a newNFTHolder
struct and add it to the list. - publish_request : gets (
offer_id
) and creates aPublishRequest
struct and saves it inpublish_requests
dict (which maps a request_id to aPublishRequest
struct). Then puts therequest_id
inproducer_requests
dict (which maps a producer account hash to a list of request_ids), also puts therequest_id
inpublisher_requests
dict (which maps a publisher account hash to a list of request_ids). A producer can accept or reject a request and a publisher can cancel any request. - approve : gets (
request_id
) and approves it, and creates anApprovedNFT
struct and saves it inapproved_nfts
dict (which maps a approved_id to anApprovedNFT
struct). then puts theapproved_id
inproducer_approved
dict (which maps a producer account hash to a list of approved_ids), also puts theapproved_id
inpublisher_approved
dict (which maps a publisher account hash to a list of approved_ids). A producer can disapprove an approved request at any time post an timestamp. - disapprove : gets (
approved_id
,amount
,publisher_address
) and disapproves theapproved_id
. If theamount
is equal to theamount
of theApprovedNFT
struct, it will remove theapproved_id
fromproducer_approved
andpublisher_approved
dicts. Otherwise, it will decrease theamount
of theApprovedNFT
struct. - buy : gets (
approved_id
andamount
) and apurse
(which the session code will pass to the contract) and if the CSPR tokens in thepurse
are sufficient based on the requirement, it will transfer the commission amount to the publisher and the remainder to the producer minus any royalties. Then it will decrease theamount
of theApprovedNFT
struct. if theamount
is equal to theamount
of theApprovedNFT
struct, it will remove theapproved_id
activateproducer_approved
andpublisher_approved
dicts. Then it creates aNFTHolder
struct for the buyer and saves it inholders
dict. [TODO] : If the buyer already owns this token, it will add theamount
to itsNFTHolder
struct, otherwise it will create a newNFTHolder
struct and add it to the list. - cancel_request : gets (
request_id
) and removes therequest_id
fromproducer_requests
andpublisher_requests
dicts. - publish_offer : creates a new offer from the producer side, and puts it in the offers dict, which maps an offer_id to offer.
- init : Initializes the dictionaries needed for the contract. It is called only once when the contract is deployed by the installer and it's not callable by any other user (or by the installer after the installation of the contract).
- Getter Functions : These functions are used for interacting with the contract from one contract to another or by session call.
Groups
- Constructor : this group is used for initializing the contract.
- [TODO] Producer : producers can mint tokens and approve requests.
- [TODO] Publisher : publishers can publish approved requests and send publish requests.
Storage Model
Deployment
This contract is deployed on Testnet (casper-test) successfully, here is the contract hash: 8259fd8ae5d5a4ecf9f93f2570336ec621fdf9e36fd252b8459c3315351952ad
Project Feautures
NFT Gating system
Producers can set a set of rules in order to sell their tokens. They can limit the buyers to accounts which have bought several other tokens by the producer (gating), or they can provide tiered discounts.
These rules (ruleset) are deployed on droplinked.com before the customer purchases the token.
NFT Storefront
droplinked.com provides a storefront in wich the producers can upload their NFTs and set their prices and rulesets, while customers can explore the NFTs and buy them. These NFT's represent both digital and physical goods.
Dependencies
~8MB
~159K SLoC