If you have a steem engine token, the first thing that needs to be addressed is how you will establish demand for your token. Otherwise it won't have value. It can be useful, it can be used for fun, it could even be a highly coveted status if done right. But it needs to aim for something that makes people consider buying. The thing that many of these have in common is that it will either pay dividends from holding (from a sustainable source), or they can be redeemed for something.

Let's say you have tied your tokens to a redemption value via the simplest method: community account voting bot. Simpler now that @holger80 has published it for anyone to customize and use (many thanks!).

How do you maintain the token economy?

Note that issuing too many tokens will make the redemption effectively useless, but on the other hand, redemption isn't going to happen for all tokens anyway.

First, just how much can a community bot redeem in total?

Well that's given by the upvote value calculation for 100% (e.g from https://steemnow.com), multiplied by 10 for the daily value that can be assigned.

Some fraction of that is driving community behavior. For the rest, that's what you can consider votes allocated for redemption.

At a fairly basic level, one can just monitor the rate of redemption and scale back token issuance if the limit is hit, and while it isn't, issue tokens at a fixed rate per period of time.

Other than that, if you know that for example the daily value that can be assigned, and you have earmarked 50% of that for community activity, then you can set up a system to tally the vote values for community votes and as soon as the 50% is reached, stop activity and wait for the following day to resume. The rest you reserve for redemption, and tally redemption votes the same way and stop redemption if daily allotment is hit.

How do you achieve predictable redemption?

Fixed % Vote

The simplest is to tie a token to a fixed % vote (how the python bot works by default, essentially). This will mean that the best redemption time is when the corresponding voting bot is at 100% voting power. This will not be the case for a shared community account that may have other activity, unless you have a queuing system whereby the bot only issues votes when its voting power is at 100%. I'm not aware of such a bot, and likely it wouldn't exist because most bots want a more predictable timing to have better curation results.

One approach is to enforce that your bot is at least above a pre announced target, say 80%. Then there's some expectation for those redeeming and anything extra is just extra gravy on top.

Fixed Value Voting

In this approach, the bot computes what % would enable a target vote value, and makes the vote if possible, or otherwise refund the input.

This can be a little awkward, because when SBD is being printed and the peg is broken, it throws things off a bit. But if you just ignore the case where SBD worth more than a dollar (since that scenario is not sustainable long term), then one approach is to adhere to what the upvote value is in terms of STEEM (this value is stable against the volatile STEEM price). The other benefit of doing so is that the steem engine market exchanges with STEEM, which makes things a lot more predictable.

How does this work? Recall that your vote value in STEEM can be computed looking at current reward pool (which is in STEEM), current assigned rshares total, and the assignable rshares of the account. Don't need to worry about price feed at all here. Then if you have something like 1 TOKEN = 0.01 STEEM, then you can find the vote weight where the resulting STEEM value matches the target and vote that amount.

The good part here is that the redemption is much more predictable. It's harder to explain though, especially given the $ value shown in the UI is in terms of price feed. And people will definitely get confused when the SBD value is too high (generally I just see it as a nice bonus).

Okay... But... How much can you give out?

Do the following. First decide what portion of the daily value you want to allocate to redemptions.

If you are using VP% based redemption, the number of tokens to issue daily should just be based on this value.

For example, let's say you decide that 50% of the daily value will be for redemption. Since you roughly have 10 full power votes a day, adding up to 1000%, you would give out 500% worth of tokens. If you decided that 1 token = 1% vote, then you can issue up to 500 tokens a day. Well, something like that. May have to watch the actual redemption rate and adjust accordingly. Interestingly, since your vote bot is collecting the tokens for redemption, those same tokens can be redistributed out without having to mint new ones, and keep a relatively self-sustaining economy.

Just some random thoughts as we finalize what we're doing with @helpie.

Oh and you might want to set your max supply to something you don't even have to think about, and only issue on an as-needed basis. That way you can avoid cases where you don't have enough to fulfill projected distribution without resorting to many decimal points (which also can be restricted... In which case you may not have enough to proceed with the plan. Ahem... Not going to name any case where that has happened, nope!)

As far as was to establish demand, this is really my least favorite. But the reason we considered it is because we will use it to replace auto voting members, and instead making them earnable by the community which can then either be redeemed or sold, giving fuller control for how we reward being part of the community and doing good things for steem.

Hopefully we'll have some fun drivers of demand. Something that will be like "I want COOL points because it can unlock all sorts of COOL magical things. Yeah I don't know what that is yet. To be continued I guess!

Posted using Partiko Android