HackMD
Bandit Club LitePaper
Links
App: https://bandit-club.vercel.app/
Frontend Github: https://github.com/AlbertSu123/ethdenverhack
Backend Github: https://github.com/AlbertSu123/banditclub
Overview
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.
Infrastructure
Overview
Key Definitions
Usage Curve:
Subscription:
Technical Components
The key components of the Bandit Club.
Smart Contracts
- Subscription handler
- Address registry
Off-chain payment relayers
Handling payments
- Needs to happen at the end of every month
- Percentage kept at the BanditDAO for future growth initiatives
Subscription
Potential fee models can be based on the following:
- 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.
Attributes of the fee model/curve - exponential curve :
- 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
Usage Curve
Usage curve: -> Just do 1 tx = 1 point. Log curve?
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? )
The DAO
- 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?
Biggest Risks:
- 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)
Long-term:
- Incentivize developers to create smart contracts
- It can turn into real-life stuff as well
