Incorporate Jesta's suggestions

[realnedscott]

Thoughts

• I will probably add controls for SMT for end-users, and explore options for token owners (with complexity/security concerns in mind), to Vessel. Seems like a good place for it.
• Can we (both community + dev team) coordinate to launch an official testnet for this? It would be good for application developers to have an environment they can test in without having to spend $3k

Considerations

The forum enables additional tokens to be exposed or launched to represent specific topics of discussion. The ability to launch these tokens can be retained by the company behind the website or granted to the website's community managers. Tokens dedicated to the website's specific topics will further spur autonomous growth of the website niche by niche. An example of this multi-token model could eventually be found in organizations such as ChainBB (chainbb.com) if it were to enable its own globally available token on its domain as well as narrowly available tokens for specific community niches, such as "gardening."

The price point (whether $1k or $3k) would be one of the limiting factors as to how many niches get filled. Specifically for chainBB, if they are $3k per token created, I don't think it would be cost-effective to launch a token for each niche, but would be cost effective to just launch a single chainBB token. Just something to keep in mind when determining the price.

It is also highly recommended that a control account does not post, vote, or hold any STEEM, SBD or tokens (other than a small amount of vesting STEEM for transaction bandwidth).

Could this be elaborated on? I'm curious to know the reasoning behind it. I assume for the security of that account (airgapping/etc)?

Feedback on Wording

"Several popular token protocols, such as Ethereum ERC-20s"

Should this be "Ethereum's ECR-20", since we're talking about protocols?

"further aligned with content creators, the businesses"

Perhaps an "and" after the comma, reading: "further aligned with content creators, and the businesses"

"By leveraging a recently architected automated market maker concept 2"

The 2 should be in brackets, as a source, [2]

"immutable on the blockchain, and leveraged correctly"

", and if leveraged correctly"

"Now their subscribers can be rewarded with crypto currency while commenting"

Everywhere else in the white paper it uses cryptocurrency as a single word.

"In this ICO, you don't send STEEM to the issuer in exchange for tokens. Instead, you vest STEEM (to yourself), and tokens are issued to you equal to the STEEM you vested."

I could see some elaboration on this. Is it only Steem powered up during the ICO window? Does the user have to perform a special power up? Would users be able to just power down before hand, then power up during the ICO to gain tokens? What's the purpose here?

"Possible inflation target"

Some examples of inflation targets could be helpful.

[iamsmooth]

Maybe this is best discussed elsewhere but is somewhat related to the comments above about ability to proliferate tokens for useful purposes and experimentation.

Since tokens were changed to use assigned decimal/hex IDs, can the fee per token be radically decreased. There still needs to be some fee to limit spam and resource use but is anything even remotely close to $1K-$3K still needed with no namespace issue? It seems vastly out of line with the cost of other operations that also consume resources such as posts or comments.

Thinking about this competitively, one can create an ERC20 token for next to nothing (just some gas fees). The real costs arise when trying to popularize it via namespace tools or marketing. There is no real cost barrier to experimentation or assigning tokens for whatever purpose you want, even a niche purpose.

[realnedscott]

Coincidentally, I just updated this to $75. Open to suggestions.

Sent from my iPhone

On Sep 17, 2017, at 4:18 PM, iamsmooth notifications@github.com wrote:

Maybe this is best discussed elsewhere but is somewhat related to the comments above about ability to proliferate tokens for useful purposes and experimentation.

Since tokens were changed to use assigned decimal/hex IDs, can the fee per token be radically decreased. There still needs to be some fee to limit spam and resource use but is anything even remotely close to $1K-$3K still needed with no namespace issue? It seems vastly out of line with the cost of other operations that also consume resources such as posts or comments.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[iamsmooth]

My suggestion would be to rely on input from devs on relative resource use compared to other operations and try to have at least a rough normalization model. I know this is something which needs to be addressed more broadly but my thought would be that if there were such a model, would the cost of a token be $75? Or would it be closer to $1?

Users can create unlimited comments (subject to bandwidth limits) which each consuming space in permanent consensus state (for unique permlink, at least, not sure about anything else). Likewise the proposal for the next hard fork is to allow free accounts (though not unlimited) and again those carry a significant cost in consensus state. it is unlikely that comments, in particular, would ever be directly charged (for UX reasons) but there should still be some sort of model on the value of how much this free service is costing and that model can inform something like to cost of a new token.

Maybe $75 is reasonable in light of actual costs but if so it will limit some token uses (okay, they should be limited in that case) such as token-per-topic or such if "topic" is an otherwise-lightweight thing (such as a subreddit) or other forms of experimentation or uses that we likely haven't though of yet.

[clayop]

Beside the developer's perspective, my thought on the cost is that it implies certain levels of commitment to the token, especially for entrepreneurs. In case of BTS, creating 4-character UIA costs around $400 and 5-character UIA needs below $10, and the result so far is over sixteen hundreds of UIAs while majority number of them are not active or have only a few holders. This can dramatically increase market orders that needs significant resources (i.e. memory) of full nodes.

I think the minimum fee level should be at which meaningfully large sub-communities can afford enough with collected rewards. For instance, for gardening category $1,000 is not that big amount and the members can collect over $1,000 via an ICO if daily payout on the tag is over several hundreds. Surely $1k is quite high for very small communities or 3rd world communities, so the amount should be carefully considered with multiple aspects.

[iamsmooth]

From the description of UIAs having different fees depending on symbol length that sounds more like a namespace issue (which does not apply here since as current constructed SMTs would not have blockchain-assigned names). I'm in agreement that the full node memory usage needs to be considered, I just wonder how significant it is compared to other uses of full node memory. For example, sixteen hundred unused UIAs might be a lot if each requires a megabyte of full node memory. It would not be a lot if each requires 100 bytes.

My interest is to avoid creating barriers that make the system less useful, as some of the examples given above such as smaller or less affluent communities, or as I previously mentioned experimental usages such as token-per-subforum that might turn out be useful but isn't really known in advance and could be very expensive to launch with unknown payoff if multiplied by the number of subforums.

I'm all for limiting or even preventing these use cases if the (memory, etc.) costs are too high, but don't do it out of inertia because the previous namespace-conservation model required "high" fees.

[clayop]

I personally view the $1000 is too much high since my perspective on the fee is "returning rewards" for having community commitments. I think it shouldn't be cheap that any individuals can create tokens without meaningful burdens, but it is cheap for communities whose members are willing to dive into deeper levels. I looked at gardening trending page for example, and the to 30 posts have about $2300, meaning that in a week they will have about 850 SBD. I think the community members want, they can collect $1000 (or someone pays first then compensated by ICO) easily. While I am still open to discussion, but my emphasis is on "not cheap for individuals but cheap for communities"

[realnedscott]

I'm liking .99c - a succinct, catchy, inexpensive number:

"Launch a token for 99 cents.. Launch a business for 99 cents Start a community for 99 cents.. etc."

Interfaces, because of the naming system, can charge more for listing, if needed.

[clayop]

My personal impression for 99c is that it sounds junk products sold at a dollar shop. I think burning STEEM or SBD is an important way to appeal investors, and SMT creation fee can play a key role. I want to consider it as "returning rewards", which are created over 20,000 per day.

[realnedscott]

What's your preferred number

Sent from my iPhone

On Sep 22, 2017, at 3:22 PM, Jaewoo Cho notifications@github.com wrote:

My personal impression for 99c is that it sounds junk products sold at a dollar shop. I think burning STEEM or SBD is an important way to appeal investors, and SMT creation fee can play a key role. I want to consider it as "returning rewards", which are created over 20,000 per day.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.

[clayop]

I have no specific number and think the whitepaper do not need to determine at this moment. Instead it can describe some basic criteria as discussed above, such as not as expensive to discourage starting businesses, but still expensive to meet expected costs and meaningfully generate profits (burn emissions).

[clayop]

After some thoughts, I think comparing to costs for running VPS can be reasonable. For instance, Digital Ocean charges $40 per month for 4G memory and 2 CPU, 60GB SSD, which seems a kind of affordable option. It equals to about $500 per year.

So I think $500-1000 would be reasonable range for SMT creation, if listing names is on-consensus and do not require fees.

[andrarchy]

I'm just a little worried about making decisions that aren't based on customer feedback. The people who should be determining the price are the potential customers and then it's up to us to meet those demands while maintaining the economics of the ecosystem. For a lot of people this up front payment is going to be a serious barrier, is there any way to do freemium, pay-as-you-go, or trial periods?

[clayop]

Generally agree with @andrarchy . So we may need to describe motivations and goals with the fee.

Little off topic but related thing is that Steemit seems overlooking profit generation models (or locking). Dash's masternode, Ethereum's ENS, Ark's modified DPOS (seemingly LPOS) all aim to lock as many as stakes and hence increase demands and the price.

With $500 fee, we may miss 500 potential token creators willing to pay $1 fee. But if we can attain one serious and well-prepared entrepreneur, we can still keep profit, while keeping premium branding for the serious business owner. I prefer having smaller number of businesses with decent capital and plans on Steem, rather having tens of hundreds tokens made just for fun and curiosity.

Regarding freemium, I think testnet should do for that purpose.

[iamsmooth]

I actually think zero is a reasonable number, pending input from the devs on the cost of consensus state relative to other operations (if it is much higher then a fee may be warranted). We already have bandwidth limiting and it may not add a lot more cost to the system to create many tokens (which have no names and aren't visible to anyone unless they are registered in some directory and are promoted) than using all their bandwidth to spam comments.

Because: 1) there is no namespace issue that is handled elsewhere (and if namespace management is added to the chain that could involve significant fees/burning to reserve/renew names); 2) there are already other ways to consume permanent consensus memory space without paying any fee (I don't know exactly what they all are or how much they use, hence I defer to the devs and/or suggest that the devs comprehensively review this and come up with a coherent strategy). I guess it would be okay for it to use a higher bandwidth multiplier the way market ops do (although that itself is a little goofy to me, since market orders do not consume permanent space, and something like comments, which use the lower multiplier, do).

The issue of 'returning rewards' is a much broader one that calls into question the entire inflationary value add of rewards (on which I'm expressing no view here) and if a consideration at all, ought to be addressed as a matter of community input and consensus not a few people deciding it on a private repo.

[clayop]

Technically, it maybe dropped to zero, but if there are many demands willing to pay more why should we give up the opportunities that increase demands? I don't think zero makes sense.

Cheap costs do not mean that the product should be cheap. If we can make a good product with cheaper price, this should be a chance for greater profits. I am against selling a great and innovative product, i.e. SMT, at a dollar or less just because we can produce it cheaply.

[andrarchy]

What about offering "free" options that include things like longer vesting contracts or hardcoded obligations to use a percentage of their tokens to burn Steem?

[clayop]

If there are ways to ensure burning Steem, I am not against the idea.

[realnedscott]

Burning coins to burn coins is overrated imv, even ignoring the fact that it reduces one of the market cap multipliers which reduces potential for attention. Better to capture creativity and create value through production. I'm more heavily leaning towards reducing cost to something as low as reasonable. Also related tangent, I'm expecting interfaces to charge more to bring tokens to the surface of their apps.

Sent from my iPhone

On Sep 25, 2017, at 12:11 AM, Jaewoo Cho notifications@github.com wrote:

If there are ways to ensure burning Steem, I am not against the idea.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.

[clayop]

Two points:

1. If you do not prefer burning, locking can be another option which do not reduce the market cap multiplier but do reduce the supply side.
2. What I am worrying with low fees is crowding-out effect by numerous junk tokens, that may not be used actively in the long-term. This consequently harms the brand image of SMT. Meaningful amount of fee enforces token creators to seriously consider value creation machanisms with the token at least over the fee level. It filters out just-for-fun creators, and resulting in better conception about SMT system and its tokens.

[realnedscott]

I agree on both points.

For 2/ I expect interfaces to do the work of filtering junk. — quality interfaces will have their own approval processes — and if they make tokens available globally then I expect they are more of a wallet. This said - it is the best argument for keeping fees high.

Once the paper is out, I expect we can get some discussion going around this.

On Sep 25, 2017, at 12:41 PM, Jaewoo Cho notifications@github.com wrote:

Two points:

If you do not prefer burning, locking can be another option which do not reduce the market cap multiplier but do reduce the supply side. What I am worrying with low fees is crowding-out effect by numerous junk tokens, that may not be used actively in the long-term. This consequently harms the brand image of SMT. Meaningful amount of fee enforces token creators to seriously consider value creation machanisms with the token at least over the fee level. It filters out just-for-fun creators, and resulting in better conception about SMT system and its tokens. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/steemit/smt-whitepaper/issues/124#issuecomment-331957591, or mute the thread https://github.com/notifications/unsubscribe-auth/ARd07f7GEmauOiupEJRZUhFSSj7elfLeks5sl-XGgaJpZM4PaQda.

[clayop]

Great. I checked the updated document and leaving rooms for further discussion seems good.

[iamsmooth]

There isn't really such a think as 'clutter' or 'junk' tokens in the current design. Tokens are identified only by hex or decimal numbers (I don't remember which was decided), and there can be an infinite number of them (subject to resource constraints). It is only when those tokens are listed in some directory or promoted that they are actually visible outside of a chain explorer and become potential for spam/clutter/annoyance.

If someone wants to create a token or even a whole collection of tokens as a test run or to experiment with them, or for some other private use, under the current design no one else ever needs to see that. It is similar to creating a wallet on something like Ethereum or Bitcoin but not publishing the address anywhere.

If there is a place for high (or at least significant relative to the market to reduce spam) fees and reducing clutter, it is in a directory, not the token itself.

Again, I will qualify as I did above that this is contingent on the token itself not implying high system-level costs (disproportionately so relative to other operations one can do with ones bandwidth) and to the extent there are high costs then those costs should be borne by the token creator, at least sufficiently so to discourage excessive use.

[clayop]

I kind of agree the fees for the directoty (or namespace) can be higher while creating token keeps low. However, the problem is SMT does not have on-chain namespace like ENS, rather have frontend level registration. So we can't ensure there will be meaningful amount of fees for the directory.

[iamsmooth]

Actually both ETH and SMT have no real token directory at the moment, as ENS isn't actually used for anything yet. Ethereum token naming is mostly handled out of band now, by the PR and marketing efforts of the token creators to get people to know about and care about their tokens. This means that junk tokens are completely invisible/unknown/ignored and those with significant efforts behind them and community support them are known. SMT afaik, currently has no specific proposal for token discovery/directory, but I guess @nedsteem has some ideas about that.

If ENS turns out to be a good way to globally identify tokens then Steem could adopt a similar sort of on-chain system. Or maybe other ways of approaching it are better, I don't know.

[clayop]

I am thinking lock-in model. For instance, X dollar equivalent STEEM is locked for SMT creation and the vested STEEM will be released after 104 weeks. This means the creator should be exposed to STEEM price volatility for two years and pay some percentage of opportunity costs (e.g. curation rewards).

One of the advantages is SMT creators do not destroy any of their capital. Also, exposure to STEEM price can motivate the creators to devote more. Also, it can significantly reduce if the X is high.

This surely can be used for front-end registration while the creation fee keep low. But what I am worrying is frontends with higher registration fees being less competitive than ones with lower registration fees. Additionally, potential threats of phishing site with deceiving token names at the frontend level (while the hash is different but hard to check for non tech savvy).

[clayop]

FYI, Ostrom's theory. http://www.onthecommons.org/magazine/elinor-ostroms-8-principles-managing-commmons#sthash.hx0aAiQQ.xOhe5swG.dpbs

Whitelist appears to be a good tool to define "group boundary" for using common resource (i.e. reward pool), see the first principle in above link.