-
-
Notifications
You must be signed in to change notification settings - Fork 354
Guide for Elysium tokenization layer
This guide is a work in progress.
First of all, you should have Firo binaries that contain the patch to allow Lelantus on Elysium. (TODO)
First step, you should start from fresh state by deleting old regtest home directory
rm -rf ~/.firo/regtest
And then start node
firod -daemon -dandelion=0 -regtest -elysium
Flag -daemon
to run program on background.
Flag -dandelion=0
to disable dandelion to force node push transaction to local mempool.
Flag -regtest
to force node to run on local testing network.
Flag -elysium
to enable elysium
There are two requirements to make Lelantus feature work on Elysium
- Lelantus enabled block has to be reached.
- Token creator has to allow the feature.
We start with generating an address and generating some blocks first.
ADDR1=$(firo-cli -regtest getnewaddress)
We would call it addr1 and would use it as the token owner and creator.
firo-cli -regtest generatetoaddress 1000 $ADDR1
For now we should fulfill 1). To fulfill 2) we would create some token.
firo-cli -regtest elysium_sendissuancefixed $ADDR1 1 1 0 "" "" "Lelantus" "" "" "1000000" 0 1
You can get usage of this command by firo-cli -regtest help elysium_sendissuancefixed
. For now we would focus on the last flag, 1 mean we would allow Lelantus feature on this token but owner still be able to update. We call this Soft Disable .
You need to mine some blocks and then ensure new token is created by command below.
firo-cli -regtest elysium_listproperties
If there is no other tokens created on the regtest network. Token id should be 3.
Run command below to create a Lelantus mint and then check that mint is pending.
# Create a lelantus elysium mint transaction
firo-cli -regtest elysium_sendlelantusmint $ADDR1 3 10# list pending lelantus mints
firo-cli -regtest elysium_listpendinglelantusmints# mine some block to make the transaction is confirmed.
firo-cli -regtest generate 1# list confirmed mints
firo-cli -regtest elysium_listlelantusmints
You should find a confirmed mint in elysium_listlelantusmints result.
But only one coin in a group could not be spend. Then we should create one more mints
firo-cli -regtest elysium_sendlelantusmint <addr1> 3 10
firo-cli -regtest generate 1# should there are 2 mints in list
firo-cli -regtest elysium_listlelantusmints
Imagine we spend a private coin on token layer but at base layer we use transparent fund to pay fee. User information would leak at base layer anyway. Then Lelantus on token layer requires some private fund as transaction fee instead of transparent fund to hide user data.
Then we would create some Lelantus mint on base layer
firo-cli -regtest lelantusmint 1# create one more to make it spendable
firo-cli -regtest lelantusmint 1# mine some blocks
firo-cli -regtest generate 10
Then we could spend token.
# generate an address to spend token to
ADDR2=$(firo-cli -regtest getnewaddress)# spend 1 token to ADDR2
firo-cli -regtest elysium_sendlelantusspend $ADDR2 3 '1'# mine spend transaction
firo-cli -regtest generate 1
Make sure token is transferred to ADDR2
firo-cli -regtest elysium_getbalance $ADDR2 3# should there is a new mint.
firo-cli -regtest elysium_listlelantusmints
Token owners have full authority to control Lelantus status. There are 4 state it can be
-
Soft disabled (0) — Users can not use Lelantus functionality and token owner can change status anytime.
-
Soft enabled (1) — Users can use Lelantus functionality and token owner can change status anytime.
-
Hard disabled (2) —Users can not use Lelantus functionality and token owner can not change status.
-
Hard enabled (3) — Users can use Lelantus functionality and token owner can not change status.
Token owner can control the status while create token or update using RPC elysium_sendchangelelantusstatus <from_address> <property_id> <status as number>
Once the transaction is mined the status would be changed. The change can be verified by the RPC elysium_getproperty
.
- Home
- Information for exchanges
- Technical and Troubleshooting
- Deterministic Masternodes
- Exchanges and Partners
- Vulnerability bounty program