Bank.vote app is part of the portfolio of the Finance.Vote company, whose mission is to define future standards of the decentralized autonomous organizations. As the company has developed a platform for publishing different tokens based on the ERC20 specification, the next clear step was to build a platform for distributing any kind of tokens to specified wallet addresses.
One of the challenges when it comes to building blockchain solutions is the cost of application usage. When the owner of the token wants to share tokens with 5 or 10 addresses - there is no problem at all, but when it comes to share tokens with thousands or millions of addresses - the cost of such operation may overcross acceptable budget.
Another important topic for our customer was to build a frontend app, which will offer the same level of visibility and transparency which is guaranteed by blockchain solutions, but will be equally performed as the standard (centralized) web application we all use every day. For both subjects our team said "challenge accepted!"
Development of the distributed applications (even if the rules of programming remains the same) is completely different than in case of "non blockchain" apps. In case of centralised applications you need to pay attention to security, scalability, performance, memory consumption, cpu utilization, etc. In case of the distributed applications your main focus is on safety of the smart contracts and cost of the gas (especially utilized during deployment). Of course security is also crucial, but most of the security related cases are covered by the blockchain network itself and on the frontend side the authentication and authorization is handled by an external provider (here MetaMask).
The optimization of the costs
To address topics related to the costs of the deployments and airdrop proces there was used a blockchain specific algorithm called "Merkle trees”. In very simplified words this algorithm allows for verification if the particular element (here wallet address) belongs to a specific set of data bases on the root of the tree hash. Thanks to such an approach, instead of publishing to the Ethereum network thousands of wallet addresses, we can publish a single (verifiable) hash. Based on this we can confirm with 100% confidence if a particular wallet address belongs to the tree or not. Moreover - to don't force the users to wait for calculating the whole tree each time we precalculate the whole tree to reduce time required for proof that a given hash belongs to the tree (significantly reduced time of confirmation).
Saving? Depending on the cost of gas at the moment of deployment and number of addresses we want to distribute tokens to it will vary between several hundreds $ up to tens of thousands of $ !!!
The performance and visibility in the web app
The blockchain networks are great when it comes to transparency, verifiability, traceability, etc. Unfortunately when considering performance... let's say they aren't so good. Centralized web apps from another hand can be very efficient when it comes to the performance. Unfortunately in this case users of the app have no idea if the version they are using at the moment is exactly the same which was deployed a few hours before. In consequence the users of the system have to trust the publishers ... which is also not an acceptable approach to our customer.
To combine both options our team has developed a pipeline in which the same application is deployed at the same time into IPFS (P2P hosting which guarantee authenticity) and classic web server. In such a scenario users of the application can use a fast and performant version of the app with option to switch (any time) to the fully transparent and confirmable version hosted on blockchain.
Our activities have led to the publication of an application that meets its goals to an extent that exceeds our client's expectations. The system is used in production and ready to handle any tokens built on the basis of the specification compliant with ERC20. Our team is currently implementing new projects for the client, systematically delivering new and improving existing products.
Moving events to the Internet meant that people who could not or did not want to attend mass events could now participate directly from their own homes. The instructional video that was part of the online activity motivated people who had not previously participated in such events to exercise.
This solution greatly expanded the convention of mass running. The main challenge in the project was to deliver high quality software in a very short time, where great emphasis was placed on preparing an effective and transparent application in terms of UI and UX.
The yield.vote application is another product of the finance.vote organization. It is an application where users can lock their funds in liquidity pools and get fixed or variable interest in return. Staking in liquidity pools supports the creation of decentralized markets.
Yield.vote has configurable management parameters that can be modified by the DAO.
We built was responsible for creating full visibility into the donor transaction process. One of the main goals was to increase the company's profitability by reducing costs. We have implemented a generic payment provider that can act as a service for multiple client applications.
The solution supports the full process of creating and identifying a charity account together with KYC/KYB identification and UBO information - Ultimate Business Owner, the so-called real benefit. Also added support for SEPA (Single Euro Payments Area) transfers and internal transfers between Public Benefit Organizations accounts.