Finally solving the good old transaction cost problem?

At least we are working on it ;)

You can also listen to this blog post!

Alexander, Full-stack Developer (Blockchain)

Our goal is to ensure that every user has the most easy and flawless access to betting and fantasy on our site. When building on such a new technology as the Blockchain, user experience can suffer immensely. So one of the major issues we have to solve with our first use case herosphere.gg (esports prediction & fantasy) is how we can guarantee a fun experience with the least possible effort for the user. Alexander, our Blockchain Developer will dig into transaction costs and user allowance in the following abstracts.

With our on-platform wallet we have found a great solution in terms of security & user experience (read more here >>). As the customer satisfaction being our highest priority we have further put some thoughts into transaction handling.

Let me update you on our status quo. But please be aware that it is work in progress — not only because we test & improve constantly but also because there is rapid technical progress opening up new possibilities.

What is the problem?

Each buy-in and pay-out is a transaction on the blockchain, coming with transaction costs and confirmation time. For each transaction on the Ethereum Blockchain you need ETH for gas even when transferring a different cryptocurrency — like our igaming token PLAY.

We think this is a bad user experience and started thinking about a solution for that. Additionally we also assume that users don’t want to pay for transaction costs every single time they enter a contest on herosphere.gg — plus wait until the transaction is confirmed just to participate. This is not the user experience we want to offer. So we had an idea and are currently drafting and testing possible scenarios from a technical, user experience and economical point of view. This is what we are working on right now:

Introducing an allowance model

Through the wallet creation process users can give an allowance to herosphere.gg to transfer funds from their wallet to the contest contract. This means that herosphere.gg deducts the PLAY from the users wallet and handles the buy-in transaction for them. We are talking about an ERC20 allowance function, which is handled by a “Controller Smart Contract”. The main advantage is that herosphere.gg can trigger the buy-in transfer. Users don’t need to enter the password every time they want to enter a contest and herosphere.gg pays the transaction costs, resulting in a better user experience.

Imagine this to be the blockchain equivalent to SEPA direct debits, so a company is able to “withdraw” money from your bank account without you actively allowing it every time you want to do a recurring payment. This makes it easier for you and the company, that can further automate their payment process. In our case however, the company has to pay the banking fees for the direct debit.

How to handle transactions costs

From a business point of view one of our challenges is also to keep transaction costs for the entire environment as low as possible. Therefore we are evaluating different actions & models.

What we already started is using a simplified method of pay-outs by “bundling users”. The smart contract receives a list of addresses of winners and transfers the specific amount to all of them at once. The costs of the bundling summarize as “one-time gas costs” plus a small fee for the data change on the Blockchain for each single user.

Right now though this only works with contests where all winners receive the same amount of prize money and doesn’t work yet for percentage based modi. A potential future scenario could be to extend the contract so that we can submit like a maplist (user : amount) but this is technically not possible yet!

A block has a gaslimit of a 8 million. Theoretically the bigger a transaction (in gas) the more difficult it is for miners to include it in a block. That means that the probability for big tx to be included in a block will decrease.

Our first try was a bundling size of about 54 transactions at 1 353 329 costs and they went through perfectly without having to pay extra gas, but the upper limit is yet to be determined when we can test it out on the mainnet.

Also it has yet to be determined whether we introduce a fair-use model for the allowance. Further tests and user feedback will help us, move on fast, improving step by step to a model that has advantages for all stakeholders without compromising the overall play experience.