6 Ways to Monetize Your Ethereum DApps (Part 2)
In Part 1 of this 2-article series we had a theoretical approach towards monetizing your Ethereum DApps. In this part we will look at some code examples that show how you can actually implement them in Solidity.
Withdrawing Funds
To start with, there needs to be a function that will allow the withdrawal of the funds to the owner’s address. This is as simple as:
This function will transfer the balance of the calling contract to the address at owner (using the very popular onlyOwner modifier pattern). If you are unfamiliar with how the keywords above work, you might want to stop reading here and resume after completing our lessons at CryptoZombies.io
Disclaimer: All of the following examples are simplified to illustrate how you can implement only the discussed functionalities. We make assumptions about the business logic, and we do not take any rigorous security measures that we would take when creating a suite of smart contracts. Always do a full security audit of your code before pushing to production!
1. Create a Crowdsale / Launch a Token
This has been described in the Official Ethereum Webpage. In order to create a secure crowdsale, it is recommended to use the audited contracts created by Open Zeppelin.
You can follow this guide, or this video for that purpose.
2. Premium Functionality / Skip the Effort
In this case, we can see that a user can bypass the winCount requirement for leveling up, by paying 1 ether. The owner would then call the previously discussed withdraw function so that they get their funds.
Note that the price of Ether may go up (or down) drastically in the future, which would change the cost of your premium feature. So in a lot of cases it makes sense to add an onlyOwner function that allows you to change the cost in the future, otherwise your app may become prohibitively expensive. This goes for all the following examples as well.
3. Take a percentage of marketplace transaction fees
In this (much simplified) example, when someone wants to buy a zombie, 10% of the price gets sent to your wallet, while the rest gets transferred to the zombie’s owner.
In order to save some gas costs, you can skip the first line of the function, which will instead leave the ether at the contract’s balance. By using the withdraw function we described earlier, you can at a later point in time withdraw all the ether that the contract has.
4. Subscription / Membership
Here we will look at examples of implementing subscription / membership business models for:
- Lifetime
- Time-based
- Usage-based
We will create a contract where certain functions will only be callable by individuals which have been marked as eligible.
Lifetime Membership
This is a simple case of creating a boolean mapping, a modifier that checks if the boolean is true, and a function that allows a user to become a member for some price.
Alternatively, instead of using a boolean for member/non-member, we could use a uint8 and have different membership tiers with access to more and more features: tier 0 for free users, tier 1 for silver membership, tier 2 for gold membership, etc. Then onlySilver() could check if the membership tier is >= 1.
Simple enough, let’s move on.
Time-Based Membership / Subscription
Here our business model will assume that the subscription costs 0.005 ether per day.
In this case when a user calls the renewSubscription function, the subscriptionExpiration gets initialized to now if necessary, and then increased by a number of days depending on how much the user paid. The onlyMember modifier can be used to check if the current time has passed the expiration date.
Usage-Based Membership / Pay-per-use
Here the business model involves a user buying function calls upfront, similarly to how you can buy API calls at a set price.
In this example, a user can buy 1000 calls per ether. Every time a user makes a call to a function that has the onlyIfEnoughCalls modifier, after checking that they are eligible for the call, the availableCalls variable is decremented.
In all of the above scenarios, you could simply add the corresponding only{property} modifier to any function, and then it would only be callable by the users who are authorized to access it.
Conclusion
In this 2-part article series we discussed and implemented some business models you can apply to your DApp when your goal is to monetize it.
I want to emphasize that all the code given in this post is a very basic implementation of each model and should be adapted to your exact needs.
Next Steps:
Loom Network is the multichain interop platform for scaling high-performance dapps — already live in production, audited, and battle-tested.
Deploy your dapp to Loom’s Basechain once and reach the widest possible user base across all major blockchains today.
New to Loom? Start here.
Want to stake your LOOM tokens and help secure Basechain? Find out how.
Like what we’re doing here? Stay in the loop by signing up for our private mailing list.
