The problem 0xReferrals solves

• Most of early-stage decentralized protocols and dApps are n-sided markets. So is the market our team is building.
• Demand side is represented by the users who consume the protocol features/services (borrowers in lending, premium payers in insurance, dApps that use the oracles and APIs).
• Supply side represented by users who would like to get an extra yield by staking, depositing their capital (lenders, delegators, protocol token holders).
• Supply side is growing naturally when demand side grows (if there is yield, there will always be capital providers).
• Bootstrapping the supply side of the markets is more or less a solved problem.
• It is the actual end-users who use new dApps to borrow, exchange etc are ultimately generators of protocol/dApp revenue.
• Up until now, dApp and protocol developers mostly used content marketing (educational blog posts, partnerships) and most recently - token incentives and yield farming. These worked very well to boostrap the supply side.
• They educate their users, write the blogposts, trying to support community (pretty time consuming task for small teams), looking for partners and joint marketing, provide bounties, yield farming options, etc. Mature protocols are looking for the ways of opening new markets and scaling. They open new positions, hire people who will make grow the community, allocate large budgets to business development. But users usually conservative and stick to existing consuming habits.
• Demand side is often a stumbling-block to grow and scale.
• It appears to be way more challenging to attract the consuming end-users to new protocols, dApps (i.e. borrowers, new wallet users) compared to attracting suppliers (i.e. LPs supplying capital, lenders, stakers, validators).
• We wanted a proven solution to this problem for ourselves and identified an easy and proven growth marketing tactic - Invite codes & Referral program.

Challenges we ran into

When we were scoping and building Invite code & Referral program we faced with some challenges (which now is a part of our roadmap):

• How do we enable a multi-program, multi-tenant referral program? We wanted a possibillity to run simultaneously 2+ referral programs without depluying a new instance of app;
• How do we enable a targeted referral programs, eg., the program used to grow usage of only Aave delegated credit capabilty? How do we generalize key concepts common to almost any protocol or a dApp (such as liquidity providers or revenues/fees)? We used 0x address of a user as a unique identifier of an invite/revenue share programs.
• Storing the invite codes offchain is acceptable for the first version of app but we consider moving this storage onchain and organise in structure based on Merkle tree.