github/darkfi
1
1
Fork 0
mirror of https://github.com/darkrenaissance/darkfi.git synced 2026-04-28 03:00:18 -04:00
Code Issues Packages Projects Releases Wiki Activity

doc/testnet: edit for grammar and clarity

Browse Source
This commit is contained in:
brid
2026-03-04 12:52:37 +01:00
parent d268ae6847
commit bdbe76c2c1
9 changed files with 178 additions and 141 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
doc/src/arch/dao.md
View File

@@ -47,9 +47,9 @@ Brief description of the DAO bulla params:
a proposal to pass. Normally this is implemented as min % of voting
power, but we do this in absolute value
* **early_exec_quorum**: minimal threshold of participating total
tokens needed for a proposal to be considered as strongly supported,
enabling early execution. Must be greater or equal to normal quorum.
* **approval_ratio**: the ratio of winning/total votes needed for a
tokens needed for a proposal to be considered strongly supported,
enabling early execution. Must be greater than or equal to normal quorum.
* **approval_ratio**: the ratio of yes/total votes needed for a
proposal to pass.
* **gov_token_id**: DAO's governance token ID.
* **notes_public_key**: notes(coins) decryption public key
@@ -421,8 +421,8 @@ it can be executed early. We should add this option to DarkFi DAO params.
> The full voting period must pass in order to be able to execute a
> proposal. A new configuration parameter was introduced, called early
> exec quorum, where we can define the quorum for a proposal to be
> considered as strongly supported/voted on, which should always be
> greater or equal to normal quorum. With this addition, we can execute
> considered strongly supported/voted on, which should always be
> greater than or equal to normal quorum. With this addition, we can execute
> proposals before the voting period has passed, if they were accepted.
~~Currently the DAO public key is used for:~~

8
doc/src/spec/contract/dao/concepts.md
View File

@@ -50,14 +50,14 @@ no longer vote on the proposal, and it is considered *expired*.
### Quorum
Quorum is defined as the minimal threshold of participating total governance tokens need for
Quorum is defined as the minimal threshold of participating total governance tokens needed for
a proposal to pass. Normally this is implemented as min % of voting power, but we do this in
absolute value.
### Early Execution Quorum
Early execytuib quorum is defined as the minimal threshold of participating total tokens needed
for a proposal to be considered as strongly supported, enabling early execution. Must be greater
or equal to normal quorum.
Early execution quorum is defined as the minimal threshold of participating total tokens needed
for a proposal to be considered strongly supported, enabling early execution. Must be greater
than or equal to normal quorum.
### Approval Ratio

44
doc/src/testnet/atomic-swap.md
View File

@@ -1,17 +1,22 @@
# Atomic Swaps
In order to do an atomic swap with someone, you will first have to
agree on what tokens you wish to swap. For example purposes, let's say
you want to swap `40` `ANON` (which is the balance you should have left
over after doing the payment from the previous page) for your
counterparty's `20` `DAWN`. For this tutorial the counterparty is
yourself.
In order to do an atomic swap with someone, you will first have to agree
on what tokens you wish to swap. For example, let's say you want to swap
`40` `ANON` for your counterparty's `20` `DAWN`. You can do this tutorial
with a real counterparty or with yourself. This tutorial assumes the
counterparty is yourself, but we will indicate which steps differ so
you should be able to do the tutorial with a real counterparty as well.
To protect your anonymity from the counterparty, the swap can only send
entire coins. To create a smaller coin denomination, send yourself the
amount you want to swap. Then check you have a spendable coin to swap
with. Note that the coin overview might look very different depending
on your activity:
The swap uses one coin per party so the counterparty only sees the
single coin you're using, not your other coins.
Note: A "coin" is a single cryptographic record. Your wallet balance is
the sum of all coins you own, and each coin must be spent entirely.
You must use a coin worth the exact amount you want to swap. To create a
smaller coin denomination, send yourself the amount you want to swap. Then
check you have a spendable coin to swap with. Note that the coin overview
might look very different depending on your activity:
```shell
drk> wallet coins
@@ -28,19 +33,24 @@ drk> wallet coins
You'll have to initiate the swap and build your half of the swap tx:
```shell
drk> otc init 40.0:20.0 ANON:DAWN > half_swap
```
Then you can send this `half_swap` file to your counterparty and they
Then you can send this `half_swap` file to the counterparty and they
can create the other half and sign it by running:
```shell
drk> otc join < half_swap > full_swap
```
They can now send it back to you. Finally, to make the swap transaction
valid, you need to sign it as well
The counterparty can now send it back to you. Finally, to make the swap
transaction valid, you need to sign it as well.
Note: If you are doing this tutorial by yourself, you don't need to send
the `half_swap` or `full_swap` file anywhere, and can just create the
`full_swap` followed by the `signed_swap` directly.
```shell
drk> otc sign < full_swap > signed_swap
@@ -68,7 +78,7 @@ Party B:
drk> otc sign < signed_full_swap_with_fee > swap.tx
```
Now the complete swap transaction can be broadcasted:
Now the complete swap transaction can be broadcast:
```shell
drk> broadcast < swap.tx
@@ -81,7 +91,7 @@ Transaction ID: d2a5e288e6ba44583ee12db9c7a0ed154c736d1aa841d70c7d3fa121c92dfc69
```
On success, you should see a transaction ID. This transaction will now
also be in the mempool, so you should wait again until it's confirmed.
be in the mempool, and you should wait until it's confirmed.
![pablo-waiting2](img/pablo2.jpg)
@@ -121,7 +131,7 @@ swap: `40.00` `ANON` and `20.00` `DAWN` . The first entry shows the
`Spent` flag as `true` and the second entry shows the `Spent` flag as
`false`. This means the transaction was successful. Since we are
swapping with ourself, we successfully spent the coins in the first
half of the transaction, and re-minted to ourselves them in the second
half of the transaction, and re-minted them to ourselves in the second
half of the transaction.
If you're testing atomic swaps with a counterparty and you can see

33
doc/src/testnet/contract.md
View File

@@ -22,7 +22,21 @@ $ git clone https://codeberg.org/darkrenaissance/smart-contract
$ cd smart-contract
```
Here, generate the contract WASM bincode and its client by executing:
We will use the provided Makefile to generate the contract WASM bincode
and its client. The Makefile uses [zkas][5], DarkFi's zero-knowledge proof
circuit compiler, to do this.
Running `make` will compile the ZK proof circuits that protect the
contract's privacy, build the WASM module that runs on the DarkFi network,
and build a command-line client for interacting with the contract.
We first need to ensure the Makefile is configured so that it can find
the `zkas` binary. That might mean you need to modify the path shown below.
```
# Path to the zkas compiler (or just `zkas` if it's in your $PATH)
ZKAS = ../darkfi/zkas
```
```shell
$ make
@@ -50,7 +64,7 @@ return back to your `drk` interactive shell.
Each contract is controlled by a secret key, from which its Contract
ID derives. To deploy a smart contract, we first need to generate an
authority keypair. The Contract ID shown in the outputs is a placeholder
for the one that will be generated from you. In rest of the guide, use
for the one that will be generated from you. In the rest of the guide, use
the one you generated by replacing the corresponding placeholder. We can
create our own contract authority by executing the following command:
@@ -105,7 +119,7 @@ history. We can also export the deployed data by executing:
drk> contract export-data {TX_HASH} > membership.dat
```
The exported files contains the WASM bincode and instruction data
The exported file contains the WASM bincode and instruction data
deployed by that transaction, encoded in `base64` as a tuple.
## Lock transaction
@@ -163,12 +177,12 @@ Secret key: {IDENTITY_SECRET_KEY}
Public key: {IDENTITY_PUBLIC_KEY}
```
> NOTE: This is a very basic example client so secrets keys are used
> as plainext for simplicity. Do not run this in a machine with
> NOTE: This is a very basic example client so secret keys are used
> as plaintext for simplicity. Do not run this in a machine with
> commands history or in a hostile environment where your secret key
> can be exposed.
Now we can can create our `register` call using our membership secret
Now we can create our `register` call using our membership secret
key:
```shell
@@ -213,7 +227,7 @@ Transaction ID: f3304e6f5673d9ece211af6dd85c70ec8c8e85e91439b8cffbcf5387b11de1d0
```
When the transaction gets confirmed, our membership commitment will
will not exist in our contract registry.
not exist in our contract registry.
### Extending the smart contract client
@@ -221,7 +235,7 @@ The template client is barebones and doesn't provide us with a way to
view the on chain records of our registry. For that purpose we can
create a new small program, or extend the client to support this
functionality. Following you will find example code for retrieving
a smart contract's on-chain records from the [JSON-RPC][5] server in
a smart contract's on-chain records from the [JSON-RPC][6] server in
`darkfid` which we can use to list our registry records:
{{#tabs }}
@@ -293,4 +307,5 @@ with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as sock:
[2]: ../arch/sc/sc.md
[3]: https://codeberg.org/darkrenaissance/smart-contract
[4]: ../spec/crypto-schemes.md#poseidonhash-function
[5]: ../clients/darkfid_jsonrpc.md
[5]: ../zkas/zkas.md
[6]: ../clients/darkfid_jsonrpc.md

130
doc/src/testnet/dao.md
View File

@@ -1,20 +1,20 @@
# DAO
On the testnet, we are also able to create an anonymous DAO. Using
the `drk` CLI tool, we have a `dao` subcommand that can perform the
necessary operations.
On the testnet, we can also create anonymous DAOs. Using the `drk`
CLI tool, we have a `dao` subcommand that can perform the necessary
operations.
DarkFi DAOs have several configurable parameters, including:
- **Proposer_limit**: the minimum amount of governance tokens needed to
open a proposal.
- **Quorum**: The minimal threshold of participating total tokens
needed for a proposal to pass (expressed as an absolute value).
needed for a proposal to pass.
- **Early execution quorum**: The minimal threshold of participating
total tokens needed for a proposal to be considered as strongly
supported, enabling early execution. Must be greater or equal to normal
total tokens needed for a proposal to be considered strongly supported,
enabling early execution. Must be greater than or equal to normal
quorum.
- **Approval_ratio**: The ratio of winning/total votes needed for a
- **Approval_ratio**: The ratio of yes/total votes needed for a
proposal to pass.
- **Governance token**: The DAO's governance token ID.
@@ -47,9 +47,9 @@ FLAGS:
ARGS:
<proposer-limit> The minimum amount of governance tokens needed to open a proposal for this DAO
<quorum> Minimal threshold of participating total tokens needed for a proposal to pass
<early-exec-quorum> Minimal threshold of participating total tokens needed for a proposal to be considered as
strongly supported, enabling early execution. Must be greater or equal to normal quorum
<approval-ratio> The ratio of winning votes/total votes needed for a proposal to pass (2 decimals)
<early-exec-quorum> Minimal threshold of participating total tokens needed for a proposal to be considered
strongly supported, enabling early execution. Must be greater than or equal to normal quorum
<approval-ratio> The ratio of yes votes/total votes needed for a proposal to pass (2 decimals)
<gov-token-id> DAO's governance token ID
```
@@ -86,13 +86,23 @@ Early Exec Secret key: 9r9URX...TZCHPL
Bulla blind: 6TVkmM...Jjd5zC
```
Since its a normal `toml` file, you may open it with you favourite
editor, modify the keys configuration and/or maintain different config
versions for different DAO members. By default all keys are different,
so its up to the DAO founders to chose what configuration they are
going to use. After configuring the file(s) properly, it can be shared
among DAO members, so they hold the generated DAO information and keys.
The view command will show us the parameters. If everything looks fine,
The DAO configuration includes several keypairs controlling different
permissions:
- **Proposer key**: Required to create new proposals
- **Exec key**: Required to execute proposals after voting ends
- **Early Exec key**: Required to execute strongly supported proposals immediately
- **Notes key**: Required to decrypt encrypted DAO-related notes
- **Proposals/Votes keys**: Required to view proposals and votes on-chain
By default, all keys are unique, giving DAO founders flexibility in
access control. DAO founders may share certain keys (e.g., proposer
key with all members, exec key only with trusted executors) or maintain
separation of duties.
Since its a normal `toml` file, you can edit it with any text editor to
modify keys or maintain different versions for different members. The
view command will show us the parameters. If everything looks fine,
we can now import it into our wallet:
```shell
@@ -140,10 +150,9 @@ Wallet Address: DX7N6v...5Lz8Pp
## Minting
If parameters are shown, this means the DAO was successfully imported
into our wallet. We use the DAO name to reference it. Now we can create
a transaction that will mint the DAO on-chain, if we hold all its keys,
and broadcast it:
The parameters shown confirm the DAO was successfully imported. We use the
DAO name to reference it. Now we can create and broadcast a transaction to
mint the DAO on-chain (requires holding all its keys):
```shell
drk> dao mint AnonDAO | broadcast
@@ -154,7 +163,7 @@ Broadcasting transaction...
Transaction ID: 2e7931f200c1485ea7752076e199708b011a504d71e69d60ed606817c5ff4bd5
```
Now the transaction is broadcasted to the network. After confirmation
Now the transaction has been broadcast to the network. After confirmation
you should see a leaf position, a mint height and a transaction hash
when running:
@@ -194,7 +203,7 @@ Wallet Address: DX7N6v...5Lz8Pp
Let's send some tokens to the DAO's treasury so we're able to make
a proposal to send those somewhere. First, find the DAO wallet address,
the DAO bulla and the dao contract spend hook.
the DAO bulla and the DAO contract spend hook.
Then create a transfer transaction as follows:
@@ -259,11 +268,11 @@ drk> dao balance AnonDAO
## Creating a proposal
Now that the DAO has something in its treasury, we can generate a
transfer proposal to send it somewhere, that will be up to vote
for 1 [block period][blockwindow](~4h), if we hold the DAO proposer
key. Let's propose to send 5 of the 10 tokens to our address (we can
find that with `wallet address`):
Now that the DAO has funds, we can create a transfer proposal to send
tokens somewhere. The proposal will be open to vote for 1 [block
period][blockwindow](~4h), if we hold the DAO proposer key. Let's
propose sending 5 of the 10 tokens to our address (we can find that with
`wallet address`):
[blockwindow]: ../spec/contract/dao/model.md#blockwindow
@@ -273,8 +282,8 @@ drk> dao propose-transfer AnonDAO 1 5 DAWN {YOUR_ADDRESS}
Generated proposal: {PROPOSAL_BULLA}
```
After command was executed, it will output the generated proposal
bulla, which we will use to view the proposal full information:
The command outputs the proposal bulla, which we can use to view the
proposal's full details:
```shell
drk> dao proposal {PROPOSAL_BULLA}
@@ -310,7 +319,7 @@ Voting status: Ongoing
Current proposal outcome: Unknown
```
We can export this proposal, to share with rest DAO members.
We can export this proposal to share with the rest of the DAO.
The exported file will be encrypted using the DAO proposals view key,
so only its members can decrypt and import it.
@@ -332,11 +341,10 @@ Broadcasting transaction...
Transaction ID: 2149d7e3a60be12c96b6c6fc7ba009717d8b229b815dd4006bbe120c31681f38
```
Members that didn't receive the encrypted file will receive the
proposal when they scan the corresponding block, but its plaintext
data will be missing, so they should ask the DAO for it.
Once confirmed, you should see a leaf position, a mint height and a
transaction hash when running:
Members who didn't receive the encrypted file will see the proposal
when scanning the block, but the plaintext data will be missing, so
they should ask the DAO for it. Once confirmed, you should see a leaf
position, a mint height and a transaction hash when running:
```shell
drk> dao proposal {PROPOSAL_BULLA}
@@ -375,7 +383,7 @@ Current proposal outcome: Unknown
## Voting on a proposal
Now the DAO members are ready to cast their votes.
First lets check the `dao vote` subcommand usage.
First, let's check the `dao vote` subcommand usage.
```shell
$ ./drk help dao vote
@@ -453,11 +461,10 @@ Current proposal outcome: Approved
## Executing the proposal
Once the block period has passed(~4h) and enough votes have been cast
that meet the required minimum (quorum), and assuming the yes:no votes
ratio is bigger than the approval ratio, then we are ready to confirm
the vote. Only DAO members with the executor key can perform this
action.
Once the voting period ends (~4 hours), if enough votes were cast to
meet the quorum requirement and the yes:no ratio exceeds the approval
ratio, the proposal is ready to execute. Only DAO members with the
executor key can perform this action.
```shell
drk> dao exec {PROPOSAL_BULLA} | broadcast
@@ -469,9 +476,9 @@ Broadcasting transaction...
Transaction ID: 808b75685d91c766574dd5a3d46206b8e145b29f3647736161d2e2b2db051444
```
Since in our tutorial the `ANON` governance tokens we used surpass the
early execution quorum, we can execute the proposal right away, if we
hold both the DAO executor and early executor keys:
Since our vote exceeds the early execution quorum, we can execute the
proposal immediately (requires both the executor and early executor
keys):
```shell
drk> dao exec --early {PROPOSAL_BULLA} | broadcast
@@ -483,9 +490,9 @@ Broadcasting transaction...
Transaction ID: 808b75685d91c766574dd5a3d46206b8e145b29f3647736161d2e2b2db051444
```
After the proposal has been executed on chain, we will see that the DAO
balance has been reduced by 5 `DAWN`, if we hold the DAO notes key,
while our own balance has been increased by the same amount:
After the proposal has been executed on-chain, we will see the DAO's
balance reduced by 5 `DAWN`, and our own balance increased by the same
amount (if we hold the DAO notes key):
```shell
drk> dao balance AnonDAO
@@ -507,8 +514,8 @@ drk> wallet balance
## Generic proposal
DAOs can vote on off-chain operations by creating what is known as
generic proposals, meaning that no on-chain action is tied to it:
DAOs can vote on off-chain actions by creating generic proposals,
which have no on-chain execution tied to them:
```shell
drk> dao propose-generic AnonDAO 1
@@ -536,7 +543,7 @@ Broadcasting transaction...
Transaction ID: 47240cd8ae28eb4d1768029b488d93fe6df6c2c6847cc987ce79f75dfcd56cdc
```
And execute it, after the vote period(1 block period) has passed:
Execute it after the voting period (1 block period) ends:
```shell
drk> dao exec {PROPOSAL_BULLA} | broadcast
@@ -547,7 +554,7 @@ Broadcasting transaction...
Transaction ID: a9d77e2d6a64372cb1cf33ed062e0439e617b88ca6374917c83cd284d788d1ce
```
Or right away, since the early execution quorum has been reached:
Or immediately, since the early execution quorum was reached:
```shell
drk> dao exec --early {PROPOSAL_BULLA} | broadcast
@@ -558,15 +565,15 @@ Broadcasting transaction...
Transaction ID: a9d77e2d6a64372cb1cf33ed062e0439e617b88ca6374917c83cd284d788d1ce
```
Executing the proposal will just confirm it on-chain, without any
other actions taken.
Executing the proposal confirms it on-chain without taking any
additional actions.
## DAO->DAO
Let's now try some more exotic operations!
Since we hold the mint authority of the `ANON` token,
instead of transfering some to the DAO, we will mint them
instead of transferring tokens to the DAO, we mint them
directly into it:
```shell
@@ -592,7 +599,7 @@ drk> dao balance AnonDAO
{TOKEN2} | DAWN | 5
```
Now we will create a second dao:
Now we'll create a second DAO:
```shell
drk> dao create 20 10 10 0.67 DAWN | dao import DawnDAO
@@ -600,7 +607,7 @@ drk> dao create 20 10 10 0.67 DAWN | dao import DawnDAO
Importing "DawnDAO" DAO into the wallet
```
And mint it on-chain:
Mint it on-chain:
```shell
drk> dao mint DawnDAO | broadcast
@@ -672,7 +679,7 @@ Broadcasting transaction...
Transaction ID: 9dd81f166115563e88262ef9ed83b15112dd72247bf48ce7b161779405830a63
```
And execute it, after the vote period(1 block period) has passed:
Execute it after the voting period (1 block period) ends:
```shell
drk> dao exec {PROPOSAL_BULLA} | broadcast
@@ -684,7 +691,7 @@ Broadcasting transaction...
Transaction ID: b78824d5d6c6e6fdb6a002848353dc60279e1c8800e2741062f8944c44796582
```
Or right away, since the early execution quorum has been reached:
Or immediately, since the early execution quorum was reached:
```shell
drk> dao exec --early {PROPOSAL_BULLA} | broadcast
@@ -719,9 +726,8 @@ drk> dao balance DawnDAO
## Mining for a DAO
A DAO can deploy its own mining nodes and/or other miners can choose to
directly give their rewards towards one. To retrieve a DAO mining
configuration, execute:
A DAO can deploy mining nodes, or miners can direct rewards to a DAO.
To retrieve a DAO's mining configuration, execute:
```shell
drk> dao mining-config {YOUR_DAO}

2
doc/src/testnet/merge-mining.md
View File

@@ -11,7 +11,7 @@ don't stop a running one to start another.
Each command to execute will be inside a codeblock, on its first line,
marked by the user `$` symbol, followed by the expected output. For
longer command outputs, some lines will be emmited to keep the guide
longer command outputs, some lines will be emitted to keep the guide
simple.
## Build binaries from source

6
doc/src/testnet/node.md
View File

@@ -11,7 +11,7 @@ stop a running one to start another.
Each command to execute will be inside a codeblock, on its first line,
marked by the user `$` symbol, followed by the expected output. For
longer command outputs, some lines will be emmited to keep the guide
longer command outputs, some lines will be emitted to keep the guide
simple.
We also strongly suggest to first execute next guide steps on a
@@ -146,7 +146,7 @@ wallet_pass = "changeme"
Once you've changed the default password for your testnet wallet, we
can proceed with the wallet initialization. We simply have to
initialize a wallet, and create a keypair. The wallet address shown in
the outputs is examplatory and will different from the one you get.
the outputs is explanatory and will be different from the one you get.
```shell
$ ./drk wallet initialize
@@ -262,7 +262,7 @@ rpc_listen = "tcp://127.0.0.1:18347"
> endpoints, so your traffic is not plaintext, as it contains your
> wallet address used for the block rewards.
To mine on DarkFI we need to add a recipient to `xmrig` that specifies
To mine on DarkFi we need to add a recipient to `xmrig` that specifies
where the mining rewards will be minted to. You now have to configure
`xmrig` to use your wallet address as the rewards recipient, when it
retrieves blocks from `darkfid` to mine. Make sure you have

14
doc/src/testnet/payment.md
View File

@@ -1,7 +1,10 @@
# Payments
Using the tokens we minted, we can make payments to other addresses.
We will use a dummy recepient, but you can also test this with friends.
For this tutorial we will use a dummy recipient, but you can also test
this with friends by replacing the recipient address with your friend's
address.
Let's try to send some `ANON` tokens to
`DZnsGMCvZU5CEzvpuExnxbvz6SEhE2rn89sMcuHsppFE6TjL4SBTrKkf`:
@@ -15,14 +18,13 @@ Broadcasting transaction...
Transaction ID: 47b4818caec22470427922f506d72788233001a79113907fd1a93b7756b07395
```
On success we'll see a transaction ID. Now again the same confirmation
process has to occur and
On success we'll see a transaction ID. Once confirmed within a block,
`DZnsGMCvZU5CEzvpuExnxbvz6SEhE2rn89sMcuHsppFE6TjL4SBTrKkf` will receive
the tokens you've sent.
![pablo-waiting1](img/pablo1.jpg)
We can see the spent coin in our wallet.
We can now see the spent coin in our wallet.
```shell
drk> wallet coins
@@ -36,8 +38,8 @@ drk> wallet coins
EEneNB...m6mxTC | false | 241vAN...KcLssb | DRK | 1999442971 (19.97253683) | - | - | -
```
We have to wait until the next block to see our change balance reappear
in our wallet.
We have to wait until the next block to see our change reappear in
our wallet.
```shell
drk> wallet balance

72
doc/src/testnet/token.md
View File

@@ -1,19 +1,19 @@
# Native token
Now that you have your wallet set up, you will need some native `DRK`
tokens in order to be able to perform transactions, since that token
is used to pay the transaction fees. You can obtain `DRK` either by
successfully mining a block that gets confirmed or by asking for some
by the community on `darkirc` and/or your comrades. Don't forget to
tell them to add the `--half-split` flag when they create the transfer
transaction, so you get more than one coins to play with.
in order to be able to perform transactions, since `DRK` is used to pay
the transaction fees. You can obtain `DRK` either by successfully mining
a block that gets confirmed or by asking for some from the community on
`darkirc`.
After you request some `DRK` and the other party submitted a
transaction to the network, it should be in the consensus' mempool,
waiting for inclusion in the next block(s). Depending on your network
configuration, confirmation of the blocks could take some time. You'll
have to wait for this to happen. If your `drk` subscription is running,
then after some time your new balance should be in your wallet.
If the latter, don't forget to tell them to add the `--half-split` flag
when they create the transfer, so you get more than one coin to play
with. Once your friend has submitted a transaction to the network, it
should be in the consensus' mempool, waiting for inclusion in the next
block(s). Depending on your network configuration, confirmation of the
blocks could take some time. You'll have to wait for this to happen. If
your `drk` subscription is running, then after some time your new balance
should be in your wallet.
![pablo-waiting0](img/pablo0.jpg)
@@ -29,13 +29,20 @@ drk> wallet balance
# Creating tokens
On the DarkFi network, we're able to mint custom tokens with some
supply. To do this, we need to generate a mint authority keypair,
and derive a token ID from it. The tokens shown in the outputs are
placeholders for the ones that will be generated from you. In rest of
the guide, use the ones you generated by replacing the corresponding
placeholder. We can simply create our own tokens by executing the
following command:
On the DarkFi network, we can mint custom tokens with a given supply. To
do this, we first need to generate a mint authority keypair, and derive a
token ID from it.
Note: The token data shown in the outputs (Token ID, Mint Authority,
Token Blind) are placeholders for the data that will be created by
you. For the rest of the guide, replace the placeholder token data with the
data that you generate.
For this tutorial we will be minting two sets of tokens. For each token
we will create the mint authority keypair that sets the token ID and
authorizes you to mint the token supply.
We do this by simply executing the following command:
```shell
drk> token generate-mint
@@ -43,9 +50,6 @@ drk> token generate-mint
Successfully imported mint authority for token ID: {TOKEN1}
```
This will generate a new token mint authority and will tell you what
your new token ID is.
You can list your mint authorities with:
```shell
@@ -57,8 +61,8 @@ drk> token list
```
For this tutorial we will need two tokens so execute the command again
to generate another one.
Now execute the command again to generate the mint authority for a second
set of tokens.
```shell
drk> token generate-mint
@@ -66,7 +70,7 @@ drk> token generate-mint
Successfully imported mint authority for token ID: {TOKEN2}
```
Verify you have two tokens by running:
Verify you have two token mint authorities by running:
```shell
drk> token list
@@ -80,12 +84,12 @@ drk> token list
## Aliases
To make our life easier, we can create token ID aliases, so when we
are performing transactions with them, we can use that instead of the
full token ID. Multiple aliases per token ID are supported.
To make our life easier, we can create token ID aliases, which we can use
instead of the token ID when performing transactions. Multiple aliases
per token ID are supported.
The native token alias `DRK` should already exist, and we can use that
to refer to the native token when executing transactions using it.
to refer to `DRK` when executing transactions using it.
We can also list all our aliases using:
@@ -97,10 +101,10 @@ drk> alias show
DRK | 241vANigf1Cy3ytjM1KHXiVECxgxdK4yApddL8KcLssb
```
Note: these aliases are only local to your machine. When exchanging
with other users, always verify that your aliases' token IDs match.
Note: these aliases are local to your machine. When exchanging with
other users, always verify that your aliases' token IDs match.
Now let's add the two token IDs generated earlier to our aliases:
Now let's create aliases for the two token IDs generated earlier:
```shell
drk> alias add ANON {TOKEN1}
@@ -127,7 +131,7 @@ drk> alias show
## Mint transaction
Now let's mint some tokens for ourselves. First grab your wallet address,
and then create the token mint transaction, and finally - broadcast it:
then create the token mint transaction, and finally - broadcast it:
```shell
drk> wallet address
@@ -184,7 +188,7 @@ drk> wallet balance
## Freeze transaction
We can lock a tokens supply dissallowing further mints by executing:
We can lock a token's supply and disallow further mints by executing:
```shell