-
Notifications
You must be signed in to change notification settings - Fork 7
Minter
-
The contract maintains several special roles : minter, admin, governance, oracle
-
The contract maintains a map of managed assets, identified by their ethereum contract address.
-
FT are stored in separated FA2 contracts. Each contract can manage several tokens. Tokens can be added on the FA2 by an administrator, but is integrated in the minter contract by the quorum.
-
Each NFT is stored in a separated FA2 (one FA2 contract per NFT). Token ids are the same between ethereum and tezos.
-
The contract collects fees on behalf on the signers, the dev pool and the staking contract, according to the current fees distribution.
-
The contract is only permissionned to call mint and burn on the FA2 contracts.
These entrypoints are permissionned : only the quorum contract can call them.
(pair %mint_erc20
(bytes %erc_20)
(pair (pair %event_id (bytes %block_hash) (nat %log_index))
(pair (address %owner) (nat %amount)))
The targeted token is identified by its ERC20 contract address. Each minting operation is identified by the block hash and the log index inside the block, that way, it is truly unique.
Part of the amount is given the user, another goes to the fees reserve, according to the current fees levels.
(pair %mint_erc721
(bytes %erc_721)
(pair (pair %event_id (bytes %block_hash) (nat %log_index))
(pair (address %owner) (nat %token_id))))
The minting unique identifer is the same as mint_erc20. Fees are collected in xtz, so a payment is expected here.
(pair %add_erc20 (bytes %eth_contract) (pair %token_address address nat))
A token address is defined as a pair of address nat. The nat here is the token_id, identifying in a multi asset fa2 which asset we should target. As always, a token is identified by its eth contract address.
The contract will try to ensure that the token_address address in an actual fa2, containing in addition the entrypoints associated with wrap protocol (mint, burn, etc).
(pair %add_erc721 (bytes %eth_contract) (address %token_contract))
Very much the same logic than in add_erc20, but we don’t need a token id. Indeed, the token_id cannot be knonw in advance, because it’s an information coming from the ethereum network, at wrapping time. As a consequence, minter contract cannot rely on a multi NFT token contract.
(pair %unwrap_erc20
(bytes %erc_20)
(pair (nat %amount) (pair (nat %fees) (bytes %destination))))
Users that want to initiate an unwrap should call this entry point. He will receive exactly the amount specify, and that’s why he must specifies fees. His balance will be check, as long as the fees. It’s possible to give more fees than necessary, but not less. Fees amount are speficied in the contract storage, expressed in BPS.
(pair %unwrap_erc721
(bytes %erc_721)
(pair (nat %token_id) (bytes %destination)))
Same logic than unwrap_erc20, but fees are collected in XTZ. Fees amount are specified in the storgae, expressed as a fix cost in XTZ.
Fees are collected in several steps:
-
For each minting or unwrap operation, fees are accumulated in the fees ledger, under the contract address.
-
A call of the different disribute entrypoints (from the quorum contract) will update the ledger, dispatching the accumulated fees to the proper recipients
-
Recipients must call one of the withdrawal entrypoints, and one ore several transfers will be issued.
(pair %withdraw_all_tokens
(address %fa2)
(list %tokens nat))
If the sender is entitled to receive fees, this entry point will drain and transfer all his available balance from the tokens inside the given contract to the SENDER address.
(pair %withdraw_token
(address %fa2)
(pair (nat %token_id)
(nat %amount)))
Same as withdraw_all_tokens but here the caller specifies an amount to withdraw. Can be usefull if the fees are kept under the custody of a smart contract, and it must be certain of the amount transfered, because this ep will fail in case of unsuficent balance.
Here are the parameters that the DAO can manage.
(nat %set_erc20_unwrapping_fees)
Changes fees collected for unwrapping erc20. Expressed in BPS.
(nat %set_erc20_wrapping_fees)
Changes fees collected for wrapping erc20. Expressed in BPS.
(mutez %set_erc721_unwrapping_fees)
Changes fees collected for unwrapping erc721. It’s an absolute value expressed in XTZ.
(mutez %set_erc721_wrapping_fees)
Changes fees collected for wrapping erc721. It’s an absolute value expressed in XTZ.
(pair %set_fees_share
(nat %dev_pool) (pair (nat %signers) (nat %staking)))
Distribution between different groups that should receive fees share. Express in percentage, the sum must be equal to 100.
These entrypoints are responsible of distribution the cumulated fees to dev pool, staking, and signers. No transfer will be triggered, only the internal ledger will be updated, and then fees recipients can call one of the withdraw entrypoints.
Everything is permissioned by the oracle
role, who is in charge of knowning which signers are entitled to receive a fees share.
For now, it’s the quorum contract, which simply pass the current quorum members. A more sophistaced approach could be introduced in future versions.
(pair %distribute_tokens
(list %signers key_hash) (1)
(list %tokens (pair address nat))) (2)
-
Signers addresses
-
tokens to distribute
Tokens must be specified, to divide the eventual gas cost of distribution all the managed tokens
Admin operations. May be given to the DAO if things are running smoothly.
(bool %pause_contract)
Toggle pause state. While paused, the contract no longer accepts to mint or burn.
(address %set_administrator)
Initiates a contract administrator change. This is a two steps process, so the new admin should call confirm_minter_admin
(unit %confirm_minter_admin)
The new admin should call this entrypoint before becoming the actual admin. Sender must be the pending_admin, and an admin change should be in progress.
(address %set_oracle)
Changes the contract oracle. Oracle is in charge of relying which signers are entitled for fees.