Summary: The current weekly burn/burn reporting method needs to be updated for the sake of transparency.
Abstract: The current state of burns is setting a number of tokens and releasing revenues from burn sources such that the burn each week appears to be that desired number. Historically, this has been forcing the number to be exactly over the threshold needed to maintain a “deflationary streak”. Recently, it has been to burn the exact same number each week, and for nearly the entirety of burns it has been used to always burn a number of tokens ending in the digits “888”.
The purpose of this has not been communicated in a readily available way, but one might surmise based on how the methodology has been used that the intention was to utilize the fixed burn numbers to use a “deflationary streak” as a marketing point, to give the appearance of consistency in the protocol generating burned tokens, and to maintain a ‘joke’ or ‘meme’ or ‘pattern’ of always burning a number of tokens ending in ‘888’.
Motivation: Unless there is strong support for the current methodology that was not mentioned prior, it is a net loss strategy that is counterproductive to the benefits of reporting on token burns. This needs to change to a full, immediate burn of weekly protocol revenues in order to fulfill the benefits of weekly reporting.
Rationale: With the current methodology, best case, it results in an uninformative report that gives an illusion of high consistency. Worst case, it erodes the image of transparency and makes burns look performative or artificial/deceptive to potential investors.
1. Transparency: The purpose of a time-series report is to give investors data pertaining to the time period in question. Artificially creating perfect consistency not only communicates no information of value to the reader, but reveals that the data being reported on is manipulated and does not represent organic platform use. A potential investor could attempt due diligence on the protocol’s activity in relation to token burn, view the official report of the team, and still have virtually no information available to them about how revenues have fluctuated over the past six+ months. To get a true sense of activity, they would need to dig through spreadsheets and transactions/balances on BSC. This is a problem.
2. Appearance: There are many projects in which the development team retains an inordinate amount of the initial mint of token supply and regularly conducts “burns” from this supply performatively to mislead investors into believing tokens are meaningfully being removed from the circulating supply. Alpaca is not such a project, but the reporting and communications they have been conducting make them appear indistinguishable from such projects. Indications are that this perception of Alpaca exists to some degree among a subset of potential investors. This is also a problem.
Any benefit of perceived consistency in platform revenue, a claim to prolonged “deflationary streaks”, or the ‘meme’/aesthetic value of burns ending in ‘888’ do not make up for these serious and fundamental failures of conducting and reporting on burns, which make up a crucial value proposition for the token.
Implementation: The team would simply continue to conduct weekly burns, but instead of releasing a predetermined number of tokens, they would burn all tokens generated by burn sources that week and report on that number.