Inspiration for attra
Money moves purposefully across the world, increasingly faster and in larger amounts. One of the most widely used instruments to makes this happen is crowdfunding.
What makes a crowdfunding campaign effective?
Whether the campaign is for an investment in a company, or for charity, we believe that traditionally the critical factor has been good PR. When the targeted public has a positive perception, then money will flow.
But can DeFi be used to improve on this model?
What if there was something, apart from PR, that could boost the effectiveness of a crowdfunding campaign?
We believe there is. So we've created attra as a proof of concept to demonstrate a few ideas about how DeFi can be used to improve crowdfunding results.
In terms of inspiration we definitely owe some to
- Aavegotchi (where pet auctions may also reward the outbid participant)
- Rari Capital (where Fuse pools allow users to get creative in DeFi)
- PoolTogether (where saving money is done collectively and includes a lottery).
What it does
As a proof of concept, attra allows users on the web to
- create crowdfunding campaigns with specifically designed incentives;
- contribute to such campaigns.
Our vision for the project is broader than what the submitted project demonstrates, namely to be a playground for experiments in mechanism design.
The anatomy of a campaign
In any traditional crowdfunding campaign there are several "game" participants with different individual incentives. attra tools enable the engineering of further incentives in order to have a better overall incentive alignment. As a result the campaign may
- have higher chances of success;
- realistically aim at higher target amounts.
attra incentives include:
- a lottery
- the distribution of DeFi yield earnings
- the favouring of participants based on specific criteria
The game actors
- the beneficiary, who "needs" the campaign in the first place; they may be a business, a foundation etc.
- the contributors, who expect good investment results, appreciation for their donations, etc.
- the campaign creator, who makes use of flexible campaign parameters
The creator
- offers contributors additional, specifically designed incentives for participation
- sets a creator fee in order to be rewarded
- may participate as a contributor
- may be the beneficiary, or a service provider to the beneficiary
Additionally, the beneficiary can also participate as a contributor. Anyone can take any role or combination of roles in a campaign - we have not limited this aspect at all.
The campaign setup is completely transparent to all parts involved.
The Lottery
The incentives we've already built in for demonstration purposes are based on a lottery that takes place at the end of each crowdfunding if the campaign target was achieved. Instead of the funds going directly to the final recipient, one or several of the contributors are chosen through a raffle.
- The winners get refunded.
- The winners receive part of the remaining funds, as a prize.
The campaign creator decides about the number of winners and the size of the prize. The prize is calculated as a percentage of the funds that remain after the winners themselves have been refunded.
DeFi yield earnings
Collected funds can be staked via another DeFi application while the campaign is running. This produces additional funds. Their allocation, again, is subject to the creator's design decisions.
- Lottery winners may receive them as a bonus
- the other contributors may receive them, to have something other than the lottery prize as a reward for participation
- the beneficiary may receive it, in order to compensate for giving up part of the funds to the lottery winners
- the creator of the campaign, additionally to the fee
- any combination of the above
Favoured participants
Favoring a participant would mean things like raising their chances of winning the lottery, allowing them to have a higher lottery prize if they win, etc.
A campaigns that favors, say, holders of token X, would both
- especially attract holders of token X
- incentivize non-holders of X to become holders
Outlook
The DeFi and favouring-based incentive models open up a broad spectrum of opportunities to partner up with 3rd party protocols. They are not demonstrated in the hackathon submission, but are key factors to the overall vision.
Currently the app is deployed on the Ethereum Kovan network. The mainnet deployment will not be on Ethereum since high gas costs would render many use cases unfeasible.
We're considering L2 solutions like the zk-rollup based StarkNet or the Polygon Network as (soon to be) viable candidates.
How we built it
The smart contracts are written in solidity and developed with the hardhat framework, which comes with many useful plugins. For the project setup we actually used the scaffold-eth boilerplate in order to quickly get going. The frontend is built with react. As a starting point we used the Moralis ethereum boilerplate. In order for the frontend to efficiently stay in sync with the on-chain part, we realized very early that Moralis Web3 was the way to go.
Challenges we ran into
Realistic Planning
Definitely the biggest challenge was to decide what to aim for within the scope of this hackathon. The idea was too big to fully implement, obviously. This was our first real blockchain project, and our manpower was quite limited. It was very difficult to plan for realistically achievable goals. One way to mitigate this was to keep a dedicated Roadmap page in the frontend, such that it was easier to let go of ideas and just reserve them for later.
Sync events from dynamically created contracts
One of the biggest technical challenges was due to a Moralis limitation that we've only discovered a few days before the deadline. For context, our initial smart contract design was such that each campaign, being a separate contract dynamically created by attra, was to be owned by the creator. Contributors interact with campaign contracts directly, and those contracts would emit events. As of now, Moralis does not support to register contract event sync via an API call. This must be done manually. They are about to add it to the SDK, but we could not wait for it. We had to change the architecture and proxy all the function calls pertaining to any particular campaign through the main attra contract. That one would also fire the event, which in turn could be registered to be synced once we deployed the main attra contract.
Last minute fun
An honorable mention in the category of challenges was the need to create a video demonstration at 4 AM with only 2 hours left to the deadline, the prototype barely working, and all of this while the kovan network was mining at a speed of 1 block every 5 minutes or so. That was fun.
Accomplishments that we're proud of
Making it through all the technical hick-ups and finally getting to a submittable version, even if the deadline was missed by a few minutes. Thanks, Chainlink :)
What we learned
Iterate!
Instead of writing the smart contracts first, and then dealing with frontend integration and data queries, we should have planned for even less features, get a working app first, and then iterate on that. Many technical necessities only became clear when we actually came to tie everything together on the frontend side.
Log in or sign up for Devpost to join the conversation.