Leo Beneficiary: Burn or SIRP

View this thread on: d.buzz | hive.blog | peakd.com | ecency.com
·@taskmaster4450le·
2.467 HBD
Leo Beneficiary: Burn or SIRP
Leo 2.0 is well underway.  A few things happened that are worthy of mention along with a question that is now up for discussion.

To start, the 30 million LEO is now official.  It went live earlier today as the remaining balance of the tokens on Hive-Engine were burned.

 https://img.leopedia.io/DQmR3rrrSH687VS1PNyr3ykwj21LeF1BZ33DQxmmmtEd7QH/image.png 

Here we can see the total amount.  No more $LEO can be created on Hive-Engine, the originator of all tokens.  That means we are at maximum amount.

# Token Burns

One of the key components to Leo 2.0 is token burns.  Having a capped token supply is further enhanced by deflationary actions.  One of the keys is to burn token, or send them to @null. 

The first way this can occur is through bridging.  Here is where the bridge between the different forms of Leo (BLEO, PLEO, etc...) on associated chains generates burn activity.  A percentage of what is bridged ends up being paid to the protocol and, ultimately burned.

We need to highlight the fact that this activity will not be seen in the null account on Hive-Engine.  Instead, this burn will take place on Arbitrum, with the LEO collected being converted to "aLEO" and sent to a null wallet address.

Another way that tokens can be burned is by LEO that is earned via posts from frontends other than InLeo.  The LEO that is earned there is sent to the null account as opposed to paying out.  This feature was enacted a number of years ago, something overlooked by most.

The final way that LEO can be burned (outside someone sending it to the null account) is through the beneficiary.  Here is where one can set the payout of, say, 5% to be burned.  Thus, if a post pays the author 20 LEO, he or she will get 19 and 1 will head to null.

Burns reduce the total LEO available.  Here is an example of what took place in the past couple hours.

 https://img.leopedia.io/DQmXdWJxUfApjyVsPL8titTa4UEMKJomoveN2f5WmdCVcRa/burn2.png 

As we can see, 1.67 LEO was burned in the last couple hours, reducing the supply.  That means we are below the 30 million.  The key is to extrapolate this idea over time.

# Leo Beneficiary: Burn or SIRP?

This brings up an interesting debate over what which way to lean.

Here is a thread by @khaleelkazi regarding the beneficiary settings in one of his posts.

 https://img.leopedia.io/DQmbSDthiUMixJWtaVSg7GRrXDgqLAbrot658msuSrb39Ns/burn.png 

As we can see, he is feeding the SIRP by sending some of the LEO he earns from this post to fund the SIRP.  This is used to pay the different token distribution mechanisms (rewards pool, Leo delegation, etc...).

With the SIRP, that are many variables, some which lock LEO up.  This is a benefit yet there can still be sell pressure from this.

Which brings up to the next option: setting null as the beneficiary.

This is what I set this article for:

 https://img.leopedia.io/DQmRMLZD6d5EYJUGfR9Eh4cZ8WHwXqtwTPipc7nduB9cFsE/burn3.png 

Using the above example, a 20 LEO payout in each of these cases would result in a 1 LEO from each.  Under the first it goes to the SIRP whereas, with my article, it is burned.

Personally, I think with a deflationary token, the burn is a better option.  Revenue is important but we want that coming from the outside.  To me, within the Leo ecosystem, it is best to torch the tokens, reducing the total float.

Ultimately, the key is to do something.  Get those tokens flowing to areas where they are locked up.  Perhaps this is a criteria to consider before placing an upvote.

What are your thoughts?



Posted Using [INLEO](https://inleo.io/@taskmaster4450le/leo-beneficiary-burn-or-sirp-ese)
👍 , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,