Namada tinkerer notes part 2

2pilot
10 min readNov 28, 2023

--

It’s tinkering time

Welcome to the second part of our tinkering journey where we discuss governance mechanism, various types of proposals and learn how to stake, earn rewards and unbond your precious NAM tokens.

If you haven’t had a chance to explore the first part yet, you can find it at this link. It explains the basics that are very usefull to better understand what we are going to discuss next.

Let’s submit a proposal

No. Different kind of proposal

Governance is a decentralized way to intoroduce changes to the chain, suggestions on how spend funds from the community pool or airdrop tokens to valuable members of the community. This is achieved via proposal mechanism.

Anyone can submit a general proposal to the chain if they are ready to freeze 500 NAM tokens for the proposal voting period. In the event that the proposal is approved or declined, 500 NAM will be returned to your wallet. However, if the proposal is considered as a spam, your tokens will be permanently removed (burnt).

Anyone with a positive NAM balance can vote for a proposal or mark it as a spam. The weight of your voice is proportional to the amount of tokens you have bonded ( discussed later ). So your influence on the protocol’s future grows with the increase in the number of tokens you possess.

Let’s see how it works by actually submitting a spam proposal, it’s a testnet after all! Export proposal properties into variables:

export PROPOSAL_TITLE="How to burn 500 NAM tokens" && \
export PROPOSAL_AUTHORS="hello@2pilot.dev" && \
export PROPOSAL_DISCUSSIONS_TO="Just voices in my head" && \
export PROPOSAL_CREATED="2024-01-01T00:00:01Z" && \
export PROPOSAL_LICENSE="MIT" && \
export PROPOSAL_ABSTRACT="Spam proposal" && \
export PROPOSAL_MOTIVATION="Because I can" && \
export PROPOSAL_DETAILS="I'll probably get slashed for that" && \
export PROPOSAL_AUTHOR="tnam1qzq77j54tpsry9ctmft9gh38j3r7wanprvjr0hs7" && \
export VOTING_START_EPOCH=798 && \
export VOTING_END_EPOCH=804 && \
export GRACE_EPOCH=810

Most of the properties like title, authors, details are self explanatory, let’s focus on the most interesting ones

PROPOSAL_AUTHOR address that you have access to and want to create a proposal from. This address should have 500 NAM tokens in possession.

VOTING_START_EPOCH — epoch when the voting will start. keep in mind it should be greater than the current epoch and multiply of 3, for example 3, 6, 9 .. etc

to check the current epoch you can run

namada client epoch

VOTING_END_EPOCH — deadline for voting for proposal. Also should be multiply of 3 and greater than VOTING_START_EPOCH

GRACE_EPOCH — epoch when proposal if passed, it’s suggested changes will come into effect. should be VOTING_END_EPOCH + 6 or more

To submit a proposal we need a json file with the following structure:

{
"proposal": {
"content": {
"title": "One Small Step for Namada, One Giant Leap for Memekind",
"authors": "bengt@heliax.dev",
"discussions-to": "forum.namada.net/t/namada-proposal/1",
"created": "2069-04-20T00:04:44Z",
"license": "MIT",
"abstract": "We present a proposal that will send our community to the moon. This proposal outlines all training necessary to accomplish this goal. All memers are welcome to join.",
"motivation": "When you think about it, the moon isn't actually that far away.The moon is only 384,400 km. We have not yet brought Namada to the moon, so it is only natural to use 101 as the prime number for our modular arithmetic operations. 384,400 (mod 101) = 95. 95 km is a distance that can be easily covered by a single person in a single day. Namada was produced by more than 100 people. So 95/100 = 0, rounded to the nearest integer. This means that Namada can reach the moon in no time.",
"details": "Bringing Namada to the moon in no time is easily achievable. We just need to pass this governance proposal and set the plan in action",
"requires": ""
},
"author": "atest1v4ehgw36g9zyydzpgycy23phxuunxdesgc6nydfsxge5x3zzgscny32pxccn2wfjg5urx3fhzxhmch",
"voting_start_epoch": 21,
"voting_end_epoch": 24,
"grace_epoch": 27,
"type": {
"Default": null
}
}
}

We already exported all of it’s variables into properties, so let’s create it ( Don’t forget to update PROPOSAL_AUTHOR, VOTING_START_EPOCH, VOTING_END_EPOCH, GRACE_EPOCH variables with your own data)

echo '{
"proposal" :{
"content": {
"title": "'"$PROPOSAL_TITLE"'",
"authors": "'"$PROPOSAL_AUTHORS"'",
"discussions-to": "'"$PROPOSAL_DISCUSSIONS_TO"'",
"created": "'"$PROPOSAL_CREATED"'",
"license": "'"$PROPOSAL_LICENSE"'",
"abstract": "'"$PROPOSAL_ABSTRACT"'",
"motivation": "'"$PROPOSAL_MOTIVATION"'",
"details": "'"$PROPOSAL_DETAILS"'"
},
"author": "'"$PROPOSAL_AUTHOR"'",
"voting_start_epoch": '"$VOTING_START_EPOCH"',
"voting_end_epoch": '"$VOTING_END_EPOCH"',
"grace_epoch": '"$GRACE_EPOCH"',
"type": {
"Default": null
}
}
}' > proposal.json

Once it’s created let’s submit a proposal to the chain

namadac init-proposal --data-path proposal.json

If there were no errors during the process anyone can find your proposal by quering

namada client query-proposal

We can see some basic information like proposal id, type, author, epoch, but no details on what this proposal is acutally suggesting. To get more info about the proposal you can run

namada client query-proposal --proposal-id 0

Just use proposal id you are actually interested in. In my case it was 0

Great, we can see all details about the proposal. Note that status is currently in pending state. This is because start epoch is 798 and we are currently on epoch 796. At epoch 798 you can see that status has changed to on-going.

once it finishes the status will be marked as ended

Should we wait some time to observe the impact our outstanding proposal has made on the world?

Bad idea

Since this proposal didn’t introduce any changes and was simply a spam proposal, nothing had changed after its conclusion.

The proposal we submited is called Default proposal and you can actually change network parameters with it by providing extra data parameter to the proposal json which should contain path to wasm code.

"data" : "<path/to/wasm.wasm>"

What could be changed ? Quite a lot:

  • you can increase or decrease minimum NAM deposit required for creating a proposal
  • number of validators in the active set
  • inflation rates and much more

Next let’s try different kind of proposal called Pgf steward

Becoming a steward

Steward is a community elected entity that could be a group of people represented by multisignature account or a single person. Once a steward is elected it will be able to submit proposals to the public goods funding (PGF) pool. In other words, steward has a right to airdrop tokens from PGF pool to the selected number of addresses if his proposal will be accepted by the community.

Let’s prepare our porposal:

export PROPOSAL_TITLE="2pilot for Steward for life" && \
export PROPOSAL_AUTHORS="hello@2pilot.dev" && \
export PROPOSAL_DISCUSSIONS_TO="Me myself and I all agreed on nominating 2pilot for Steward" && \
export PROPOSAL_CREATED="2024-01-01T00:00:01Z" && \
export PROPOSAL_LICENSE="MIT" && \
export PROPOSAL_ABSTRACT="2pilot for Steward for life" && \
export PROPOSAL_MOTIVATION="There are no other candidates currently so I should win !" && \
export PROPOSAL_DETAILS="2pilot should be a good and worthy steward" && \
export PROPOSAL_AUTHOR="tnam1qzq77j54tpsry9ctmft9gh38j3r7wanprvjr0hs7" && \
export STEWARD_ADDRESS=$PROPOSAL_AUTHOR && \
export VOTING_START_EPOCH=807 && \
export VOTING_END_EPOCH=810 && \
export GRACE_EPOCH=816

As you might have noticed, there haven’t been many changes from the previous proposal parameters. We only have the STEWARD_ADDRESS variable, which serves as our nominee. It should be equal to the PROPOSAL_AUTHOR And of course there are some updates to the epoch parameters.

Let’s create new proposal file and call it steward_proposal.json

echo '{
"proposal" :{
"content": {
"title": "'"$PROPOSAL_TITLE"'",
"authors": "'"$PROPOSAL_AUTHORS"'",
"discussions-to": "'"$PROPOSAL_DISCUSSIONS_TO"'",
"created": "'"$PROPOSAL_CREATED"'",
"license": "'"$PROPOSAL_LICENSE"'",
"abstract": "'"$PROPOSAL_ABSTRACT"'",
"motivation": "'"$PROPOSAL_MOTIVATION"'",
"details": "'"$PROPOSAL_DETAILS"'"
},
"author": "'"$PROPOSAL_AUTHOR"'",
"voting_start_epoch": '"$VOTING_START_EPOCH"',
"voting_end_epoch": '"$VOTING_END_EPOCH"',
"grace_epoch": '"$GRACE_EPOCH"'
},
"data" :
{
"add" : "'"$STEWARD_ADDRESS"'",
"remove": []
}

}' > steward_proposal.json

Notice that json contains new data field. You can add steward address to add field if you consider him worthy and you want to nominate him. You can also provide list of steward adressess that you don’t like into remove field.

Submit proposal to the chain

namadac init-proposal \
--pgf-stewards \
--data-path steward_proposal.json

note--pgf-stewards flag which is specific to PGF proposals. If you want to nominate a steward or initiate an airdrop as a steward you should add this flag to your init-proposal command

To list all proposals and see if newly submitted proposal is there run

namada client query-proposal

Indeed it’s there. Now let’s try voting ( make sure you have exported your ACCOUNT_KEY_1 like we did in the previous chapeter )

namada client vote-proposal \
--proposal-id 1 \
--vote yay \
--address $ACCOUNT_KEY_1

You might get the following error.

That’s because voting period will start in the future as was described in the proposal properties. But after some time we can vote and the result will be similar to

When the voting period will end you can check proposal results

namada client query-proposal-result --proposal-id 1

Oh no, my proposal got rejected.

Better luck next time !

Also, it is showing 0.000000 yay votes, but I’ve definitely voted for myself. The reason for that is we need to bond tokens to a validator first, a topic we’ll delve into in the next chapter.

If you were selected as steward you can nominate addresses to receive fundings by changing data field to

"data" : {
"retro": [
{
"target": {
"amount": 1337,
"address": "3pilot"
}
}
]
}

which, if passed, will grant 1337 NAM to 3pilot.

Eplore more funding options here.

A Day in the Life of a Delegator

Let’s try on delegator’s shoes, shall we?

But first, let’s explore who a delegator is and why one might choose to become one.

Basically anyone with positive NAM can become a delegator. All you need to do is to bond your tokens to a validator. Ok, but what does it mean to bond and who is validator you might ask ?

Let’s explain it to Pikachu

A validator is a participant in the network responsible for validating and confirming transactions. They ensure the accuracy and legitimacy of transactions before they are added to the blockchain. Validators reputation and weight is built on maintaining the integrity of the system.

Bonding is like putting your NAM assets in a secure partnership with a validator. You are locking your tokens and, in return, receive rewards every time a new block is produced. Rewards depend on the inflation rate, the amount of NAM tokens you bonded, validator commission, and performance. If a validator does not produce enough valid blocks within a given time window, he will get slashed, and so will you. So choose your validator wisely. You can always unbond your tokens, but it will take some time, usually 14 or 21 days before they become liquid.

Btw, all those parameters we just discussed — like the inflation rate and validator performance window — could be modified via a default proposal. Also, being a delegator is a prerequisite to vote for such proposals, without it your vote weight will be simply equal to 0.

Ok, after this brief intro let’s try actually delegating to someone. First check your balance

namada --base-dir $BASE_DIR client balance \
--ledger-address $RPC \
--token NAM --owner $ACCOUNT_KEY_1

Check active validators by running

namadac bonded-stake

Bond tokens to your favourite validator. Don’t forget to export his address into VALIDATOR_ADDRESS variable.

namadac bond \
--validator $VALIDATOR_ADDRESS \
--amount 10 \
--source $ACCOUNT_KEY_1

Let’s see if the stake for the selected validator increased

nope, it hasn’t. But what about our balance.

It’s a scam ?

Catch me if you can

Not really. We need to wait 2 epochs to see the effect. When you check bonded stake later you should see the updated amount. Also, when you bond tokens to a validator, he doesn’t have control over them; only you do. However, they will receive a commission from your rewards.

After few epochs check the stake again

If you want to unstake your tokens run

namada client unbond \
--source $ACCOUNT_KEY_1 \
--validator $VALIDATOR_ADDRESS \
--amount 5

The countdown starts from epoch 816 and you will be able to withdraw them after 6 epochs.

To check actual unbond status execute

namada client bonds --owner $ACCOUNT_KEY_1

Once the time comes you can run the following command to make your tokens liquid

namada client withdraw \
--source $ACCOUNT_KEY_1 \
--validator $VALIDATOR_ADDRESS

Keep in mind, you cannot use your shielded address to bond. But let’s try it, just in case.

namadac bond \
--validator $VALIDATOR_ADDRESS \
--amount 3 \
--source $PAYMENT_ADDRESS_1

or from your spending key

namadac bond \
--validator $VALIDATOR_ADDRESS \
--amount 3 \
--source $SPENDING_KEY_1

Nope, no chance.

To learn more about governance, delagating and validating checkout out the official docs and ask questions in friendly discord channel.

--

--