Frustrations of a Dapp developer

I’ve spent years developing Dapps. Building is an incredibly fulfilling journey, however, it comes with frustrations. This article will focus on the technical aspects of those frustrations and how I’ve used what I’ve learned to guide Fantom into the best Dapp developer environment.

Callback hell

Dapp webapps are prone to callback hell due to the nature of RPC’s in blockchains. A traditional API endpoint will normally give you an immediate synchronous result. If I ask a math API endpoint the answer to 2+2 it immediately returns 4 for me. Blockchains *traditionally* need to wait for consensus to first order the transactions, they are only executed after the block is included, and even then you need to wait a few blocks to avoid re-orgs. So if I asked a smart contract via RPC the answer to 2+2, it would submit the transaction, wait for consensus to order and have a block executed, wait a few blocks (to avoid reordering), and then have the result.

As you can imagine this is a long process (upwards of tens of minutes in something like Bitcoin and tens of seconds in something like Ethereum). This means you can’t have a synchronous results, instead, you as developer need to write “pull patterns”, where you send the request of 2+2, and then continuously request the RPC if it has the answer. This is a bad development experience and a bad end user experience.

In Fantom, our aBFT consensus engine has true finality (no longest chain rule), once a transaction is finalized it can not be rolled back. Consensus is also reached sub second (average 700ms — 900ms). This allowed us to be able to make our RPC’s synchronous. With Fantom RPC’s once you send the request and receive a response, the transaction has been finalized, included, and cannot be rolled back, all in a few milliseconds.

Understandably this is a much better UX experience for both developer and end user.

Re-orgs

Most of us would have used webapps where after we submit a transaction, we are prompted by a screen “Confirming 1/10”, this pattern exists because traditionally blockchains use the “longest chain” rule for probabilistic finality. Meaning, after ~10 blocks (relative per blockchain), it becomes theoretically “safe” to assume the transaction is final. This is because after that amount of time, it is unlikely, that a new longer chain is proposed.

This can be a frustrating process, both for the developer (because they have to custom build the confirmation and polling process), and for the end user (since they need to sit around and wait till they can perform their next action).

With Fantom’s aBFT consensus, we have true (or guaranteed) finality. No longest chain. As soon as a transaction is received, it is confirmed. No need for re-org patterns in development or UX.

User onboarding

User onboarding inevitably means user education. Let’s say you create a dapp, and you want to advertise it, you create a small campaign on AdWords or something similar. Your click through dropoff becomes incredibly large, because you have so many barriers to entry. First they need a wallet (and let’s face it, unless you are tech native; private keys and mnemonics are scary), next they need fees to pay for gas (which is hard to get and often requires centralized bridges such as exchanges, requiring KYC, etc), and even then simply interacting with the wallet is hard. All of this needs to happen before they have even registered on your webapp.

Understandably this is a bad first introduction for new users. So inevitably, dapps only target existing crypto natives, which hampers growth and adoption opportunities.

The above is why in Q2 and Q3 we are releasing Gas subsidies and Smart Wallets. Gas subsidies means that you as developer, or even your community, can subsidise your contract, allowing anyone that interacts with it, to not require gas. This means the need to have gas to interact is removed as a first barrier. Secondly, our on-chain smart wallets allow users access via standard social auth (google / facebook / login with fantom / etc), no need for storing mnemonics or private keys, and allows for full social recovery. By releasing these two features it immediately removes the new user onboarding frustration.

Revenue and funding sources

Crypto revenue and funding tends to be front-loaded, this creates a lot of additional stress for projects and ends up turning projects into treasury managers as much as developers, it subtracts focus and removes a lot of room for growth. It also greatly increases delivery pressure. Instead we’ve been focusing on how we can create more sustainable (in exclusion of the foundation) and realistic funding models.

For this reason we have created a few easy to access funding pipelines;

1. Ecosystem Vault — 10% of all Fantom transaction fees accumulate to the ecosystem vault, anyone can create a proposal to release funds, and validators vote on the validity of the proposals. It’s a simple straightforward process and requires no interaction with the foundation.
2. Gitcoin Grants — Quadratic funding has proven to be a great community driven mechanisms, this is continued by Gitcoin having launched on Fantom.
3. Gas Monetization — 15% of all gas fees generated by your contracts are provided as revenue share for developers.

The above allow for 3 distinct (and growth aligned avenues) for funding;

• Idea / concept — ecosystem vault and proposal is a good sanity check of your idea and startup funding
• Community growth — Gitcoin grants allows for your community to help increase awareness and fund your growth, as your community grows, your gitcoin matching grows
• Platform growth / usage — As your app gains users and momentum, so do your on-chain transaction, allowing for sustained revenue, some of this revenue can be used for on-boarding new users via gas subsidies, creating a more positive on-boarding experience.

The above 3 mirror traditional funding pipelines and removes the overhead of large treasury management and better aligns expectation management for teams (also means you can focus on dev, and not the VC roadshow)

Learn more https://fantom.foundation/blog/how-to-get-funding-on-fantom/

Resources, growth, and education

I find that most Blockchains, due to their large treasuries, often focus too much on the large brands. Blockchains to me are no different than the internet evolution. The companies that dominate today’s internet did not exist pre-internet, they did not partner with large pre-internet brands to become who they are today. Instead they all formed bottom up. I believe the same will be true for Blockchain. Our next biggest brands won’t be internet first, but will be blockchain first. Blockchain is a distinct switch from internet business models as it changes where the data ownership lies, from company to end-user. This to me means that the current large brands simply won’t be able to get value out of Blockchain other than some trial proof of concepts.

For that reason, we believe focus should be on the new generation of developers, to that end we have decided to cultivate an environment of easy accessible education and development opportunities. We will be hosting small, accessible hackathons every 3 months, the first of which we kicked off this month. These are to help educate and develop the next generation of builders.

Our long runway allows us to think in terms of years instead of months, and we want to cultivate the next generation.

Conclusion

I’ve learned a lot dedicating my last few years to Dapp development, and believe I have a unique insight towards creating the perfect environment for Dapp developers. This insight and the security of a 30 year runway will create the perfect condition for Dapp developers to be able to unlock the true potential of blockchains.

Come join us and build on Fantom https://fantom.foundation/get-started/#for-developers