We integrated contracts that allowed users to send collected fees to other chains via GMP.
We used web3modal and walletconnect.
We used the token swaps API to swap the native token that you collect for other tokens that the user or dao might want.
We used the pocket network rpc
Bandit Club is a new paradigm in smart contract monetization. Individuals pay a subscription fee to Bandit Club based on their addresses total volume. Bandit Club keeps 10% of the subscription fee. The remainder is distributed to the deployers of the smart contracts that the individual user has interacted with. It will initially be divided and based on # of interactions with each contract, but the DAO can change the pricing structure as necessary. Smart contracts can opt to only take users if they are Bandit Club subscribers, thus ensuring they are getting paid on every interaction. This will create a powerful feedback loop where more people will subscribe to gain access, which will in turn have more developers add the restriction on their contract, which will encourage more people to subscribe, etc. There is near zero fork risk for n+2 protocol after n, n+1 protocol on board as they inherit their network effects. Smart contracts can currently only monetize with fees (introducing fork risk) or tokens (introduce regulation risk, and lacking USD-denominated cashflows). Bandit Club introduces a third option. This allows DAOs, communities, and developers to correctly monetize without harmful crypto business practices.
We deployed to base testnet and this helps incentivize builders to build on base!
We used web3modal and walletconnect.
This is a fully self functioning business, which once it hits an inflection point will scale to every contract on the chain.
We integrated contracts that allowed users to send collected fees to other chains via axelar.
We gave users the option to use the CoWSwap API to swap the native token that you collect for other tokens that the user or dao might want.
We used chainlink functions
For a better formatted version, check out: https://hackmd.io/@albertsu/bandit-club
Comment
App: https://bandit-club.vercel.app/
Frontend Github: https://github.com/AlbertSu123/ethdenverhack
Backend Github: https://github.com/AlbertSu123/banditclub
Bandit Club is a new paradigm in smart contract monetization. Individuals pay a subscription fee to Bandit Club based on their addresses total volume. Bandit Club keeps 10% of the subscription fee. The remainder is distributed to the deployers of the smart contracts that the individual user has interacted with. It will initially be divided and based on # of interactions with each contract, but the DAO can change the pricing structure as necessary.
Smart contracts can opt to only take users if they are Bandit Club subscribers, thus ensuring they are getting paid on every interaction. This will create a powerful feedback loop where more people will subscribe to gain access, which will in turn have more developers add the restriction on their contract, which will encourage more people to subscribe, etc. There is near zero fork risk for n+2 protocol after n, n+1 protocol on board as they inherit their network effects.
Smart contracts can currently only monetize with fees (introducing fork risk) or tokens (introduce regulation risk, and lacking USD-denominated cashflows). Bandit Club introduces a third option.
Risks: pay to play may not work in crypto.
Design of the usage curve should come first. That is the most complex/sensitive wheras the fee model is pretty arbitrary and will be derived from usage curve.
Usage Curve:
Subscription:
The key components of the Bandit Club.
Smart Contracts
Subscription handler
Address registry
Off-chain payment relayers
Needs to happen at the end of every month
Percentage kept at the BanditDAO for future growth initiatives
Volume per address
Assets in per address -> this seems like best approach
Total assets per address
This makes sense for determining relative placement within tiers, but how to determine an absolute price to charge? e.g. the factor to multiply each tier by.
The subscription fee would rise with the increase in benchmark variable (above). User’s can’t transact without upgrading they reach this upper limit. Compute power cost approach.
The growth would slow down as the number gets bigger
Encourages players to do as much volume as
possible
Leading essential question: How do we determine the value of the protocol??? How do we quantify this value from on-chain data?
Variables at play:
(time deposited - time withdrawn) -> for lending protocols
number of transactions -> for dexs
entropy of the protocol within the system (MEV, blockspace measurement? proximity to blockspace priority/MEV within the network? )
Token distribution needs to be decentralization
Governance is essential; they are at the center of everything running functionally
Need to incentivize people somehow to contribute
Ideally protocols/protocol token holders are incentivized to contribute heavily, thus porting over their own governance members.
^^ do we want to incentivize this further? thus make sure protocols who join and don’t get involved with governance suffer and are incentivized to leave? Or do we want to go with the governance-as-a-service route and have our expert governance teams become a public good within the club?
Non-continuous fee model
Getting developers over the hurdle versus invisible fee
Incentivize developers to onboard new users by giving them a % of subscription payments
Make sure the flywheel doesn’t become a promise of future value for the token.
Whack a mole (Solved with EOAs and Waymont)
Incentivize developers to create smart contracts
It can turn into real-life stuff as well