Home » Business » Crypto » Inside the blockchain developers’ mind: Building a free-to-use social DApp

Share This Post

Business / Crypto

Inside the blockchain developers’ mind: Building a free-to-use social DApp

Inside the blockchain developers’ mind: Building a free-to-use social DApp

Cointelegraph is following the development of an entirely new blockchain from inception to mainnet and beyond through its series, Inside the Blockchain Developer’s Mind, written by Andrew Levine of Koinos Group.

In my first article in this series, I explained why Ethereum and Steem haven’t been able to deliver a mainstream social decentralized application (DApp). In my second article, I explained how EOS attempted to combine features of both chains but it did so in a way that still required users to buy high-priced random-access memory (RAM) for accounts and smart contracts.

In this article, I want to take a different approach to this problem, not based on comparisons to existing platforms but based on first principles. Instead of constraining our imaginations based on the limitations of the earliest attempts at general-purpose blockchains, let’s, instead, look at the problem from the developer’s perspective. What do they need in order to deliver the user experience that mainstream users require? In my previous article, I described this as “fee-less without exceptions.” In other words, they want totally free-to-use applications.

Building a free-to-use DApp from first principles

The very first thing that a user will need to use an application of any kind is an account, so introducing a fee here would immediately create a negative user experience. We want to minimize friction for the user so that we can maximize virality — we certainly don’t want to force them to buy an account. But, we don’t want to solve this problem by simply forcing the developer to pay that account creation cost because this will increase their costs.

Related: Gas-free transactions will revolutionize Web3

This problem is an easy one because it has already been solved by Bitcoin and Ethereum, both of which allow users to create addresses for free. Thinking from first principles then, if we don’t want developers or end-users to have to pay for accounts, we need a blockchain with addresses that function as accounts.

Who pays?

Using Bitcoin or Ethereum-style addresses allows us to create accounts without either the end-user or the DApp developer having to eat the fee. Great. But, now we want people to actually use the decentralized application which means that we want them to run a computer program on a decentralized computer and consume some of the computer’s resources. We want to let them do something that will have a real-world cost that someone has to pay. It’s just a matter of who, right? Well, this assumes that there is only one way to charge people.

This is precisely where first-principles thinking provides so much value. Fees are the traditional way we charge people for using blockchains, so if we just assume that this is the only solution then the only conceivable option becomes who pays the fee, not whether there is an alternative approach to the problem.

Related: The power of cheap transactions: Can Solana’s growth outpace Ethereum?

Charging opportunity cost

Taking people’s money is one way to impose a cost (i.e. decreasing their token balance) but there is another kind of cost: opportunity cost. Taking people’s ability to use their tokens (i.e. their money).

If we could create a decentralized system for “charging” people to use the blockchain, not by taking their tokens, but by taking away their ability to use their tokens (for a period of time), then we could allow them to use the blockchain without taking any of their tokens.

Not only that, but once that period of time is over, they could choose to use the blockchain more, meaning that they wouldn’t have to constantly be buying more tokens just to be able to continue using the application they love. This would dramatically increase user retention and further maximize growth.

Video game experience

We now have a mechanism for charging users that doesn’t feel like a fee, but our objective is to deliver a mainstream user experience. Requiring people to consciously lock cryptocurrency tokens before they can use an application is not a mainstream user experience.

If we can’t require people to consciously lock tokens, that means we need a system that allows people to simply use the blockchain without any thought. All that means is that the system has to decide the size of the opportunity cost instead of the user. Taking this decision out of the hands of the user allows us to design the system so that the size of the opportunity cost is as low as possible, all while maintaining economic sustainability. This gives the user confidence that they are never “overpaying” (even if it is only an opportunity cost) while again maximizing growth by lowering barriers. The cheaper transactions are, the less they feel like fees — the better the user experience — and the faster we can expect the user base to grow.

Of course, the user deserves to know how much of their tokens will be locked if they choose to perform the action. What we want is basically a mana bar from a video game. The user should be able to see how much free usage of the blockchain they have based on the liquid tokens that they have in their wallet. When they go to perform some action that consumes blockchain resources, they should be able to see how much of their mana will decrease when they perform the action. If they find that cost acceptable, they simply perform the action, such as minting a nonfungible token (NFT), their mana is consumed and the right amount of tokens are locked for the set period of time. Wouldn’t that be great?

The final barrier

There is one last problem: With the system we have described, the end-user still has to have some tokens in their wallet. Generally, that means that they still have to make a purchase (of tokens) before they can use the application. While we still have a pretty good user experience, telling people they have to spend money before they can use an app is a barrier to entry and winds up feeling a whole lot like a fee. I would know, this is exactly what happened on our previous blockchain, Steem.

To solve that problem, we added a feature called “delegation” which would allow people with tokens (e.g. developers) to delegate their mana (called Steem Power) to their users. This way, end-users could use Steem-based applications even if they didn’t have any of the native token STEEM.

But, that design was very tailored to Steem, which did not have smart contracts and required users to first buy accounts. The biggest problem with delegations is that there was no way to control what a user did with that delegation. Developers want people to be able to use their DApps for free so that they can maximize growth and generate revenue in some other way like a subscription or through in-game item sales. They don’t want people taking their delegation to trade in decentralized finance (DeFi) or using it to play some other developer’s great game like Splinterlands.

We want users to be able to use a specific DApp without having to buy tokens first, and, as always, we don’t want the developer to have to spend any money to make this happen. That last part is tough because the traditional way to solve this problem is by designing the smart contract so that the developer can choose to pay the fee instead of the user. But, remember, we’ve already solved this problem because no one is paying a fee for anything, just an opportunity cost. As long as the developer has tokens, they can choose to pay the “mana” that someone needs to use their application.

Free for developers?

But, what if the developer doesn’t want to buy tokens? What if they have an existing application with a thriving user base that the platform would be lucky to attract? It’s in the best interest of large token holders to attract high quality developers to a platform so they can just do the same thing. The stakeholder could let the developer set them (the stakeholder) as the “payer” of mana for the developer’s smart contracts.

The stakeholder isn’t losing any money by doing this but they’re still able to deploy their capital to support value creation and growth, which is great. If the stakeholder provides their mana to a developer whose app adds tremendous value to the platform, then the value of their token holdings will go up. If the developer’s app doesn’t add value, the stakeholder has an incentive to stop providing their mana to that developer and find someone else who can make better use of their mana.

We have now figured out not only how to make a DApp free-to-use for the end-user, as an added bonus we have figured out how to make the blockchain free-to-use for developers while giving large stakeholders a way to invest in growth and value creation without sacrificing any of their token holdings.

Impossible?

But, all of this is just in theory right? Actually, no. What I’ve described here is exactly how we’re building Koinos. In fact, all of these features are already live on our current testnet with the third and final version of the testnet coming soon. If you want to learn more about mana, you can read the white paper here.

This article does not contain investment advice or recommendations. Every investment and trading move involves risk and readers should conduct their own research when making a decision.

The views, thoughts and opinions expressed here are the author’s alone and do not necessarily reflect or represent the views and opinions of Cointelegraph.

Andrew Levine is the CEO of Koinos Group, a team of industry veterans accelerating decentralization through accessible blockchain technology. Their foundational product is Koinos, a fee-less and infinitely upgradeable blockchain with universal language support.

[flexi-common-toolbar] [flexi-form class=”flexi_form_style” title=”Submit to Flexi” name=”my_form” ajax=”true”][flexi-form-tag type=”post_title” class=”fl-input” title=”Title” value=”” required=”true”][flexi-form-tag type=”category” title=”Select category”][flexi-form-tag type=”tag” title=”Insert tag”][flexi-form-tag type=”article” class=”fl-textarea” title=”Description” ][flexi-form-tag type=”file” title=”Select file” required=”true”][flexi-form-tag type=”submit” name=”submit” value=”Submit Now”] [/flexi-form]

Share This Post

Viewing 1 post (of 1 total)
Viewing 1 post (of 1 total)
  • You must be logged in to reply to this topic.