We absolutely are excited to tailor cohorts to each chain’s priorities, at least from our side. I am excited to see the finalization of SOS to do so. Also of course, if we have programs running on Arbitrum and Polygon, they will have 2 different applications and the teams will sort themselves. In general, many teams will have a preference for what chain they will want to launch on, and they really get the final choice.
DAOs will fund each cohort separately. As far as funding model, we have an initial deployment fee, a 10% capital allocation fee, trading fees from DEXs and we get some of each tokens that are launched.
We are currently building a new UI that can handle multiple chains and will be shared with Arbitrum and Polygon to amplify network effects, IMO the people buying tokens care more about the project than necessarily what chain they are on, so we want to make the experience as easy as possible.
And of course, we are a small team and will be managing both chains with the same team.
I would imagine we would work with an AAE, probably the foundation… as that seems to be the direction the DAO is moving.
For KPIs I have them here:
KPIs & Success Metrics
To measure success, we will track:
Onchain Growth – 10x – Market cap growth (in ARB) compared to ARB granted to teams. E.g If we give the teams a total of 1M ARB, we will produce 10M ARB worth of market caps
ARB Demand Ratio – 25% – Ratio of ARB in protocol vs ARB granted to teams. E.g If we give the teams a total of 1M ARB, we will capture 1.25M worth of ARB in the protocol, creating 250k worth of ARB buying pressure.
Sustained Value – 1 year – Long-term market cap growth (in ARB) of tokens. E.g The 10x growth will last for at least a year.
First-time Arbitrum Users – 500 – Number of q/acc participants new to Arbitrum that buy more than $10 of tokens. E.g 500 users that pass our sybil filter will have never used Arbitrum before.
On-Chain Activity – Varied – Trading volume, user participation, and liquidity metrics. This will be tracked but it is so gameable, it’s not worth creating an exact metric, but we will create a lot of onchain activity.
We aren’t planning to run them at the same time, but I’ll be honest, we can’t always control these things. There are a lot of timelines and resources to manage with lots of different teams so we will just do what we think is best given the situation. There might be some network effects to running them at the same time though! So we’ll think about it 