Rollups need an eco-system license
Support building the TVL and eco-system moat
As a follow up to Rollups: centralised front-ends and decentralized front-ends, one of the core discussions in the article is about the type of a moat a rollup project should seek to build and fend against the competition:
The outlined moats include:
Developer moat. Open-source everything and an army of developers will build for your system. No one wants to build for Goliath the rent seeker. Focus on Developers, Developers, Developers!
Fork moat. Encourage teams to fork and re-instantiate your rollup, ideally on your own L2 platform.
TVL and user moat. The more coins locked in your rollup network and the forked instances, the greater liquidity moat for your eco-system and a snowball effect of more people building with it.
It is essentially the same moat that go-ethereum (Geth) has built today and why Ethereum is still the leading smart contract platform.
Many of the top projects rely on a modified version of Geth under the hood including Arbitrum, Avalanche, Binance Smart Chain, Optimism, Polygon, etc. The wide-spread adoption of the EVM has built a moat as developers can implement their project with a single set of tooling and re-deploy it across all EVM compatible platforms.
While it is difficult to measure, it is arguable that forking Geth has helped cement Ethereum as the indisputable King amongst developers. One of the reasons behind the success of go-ethereum’s adoption is its permissive GPL license.
It removes liability and warranty of the Ethereum developers while allowing anyone to re-instantiate the software for their desired use-case. The only condition is that all code built on top of it must be open-sourced too which is perfect for a budding new cryptocurrency network. Other projects have adopted various permissive licenses including BSD-3, MIT and Apache. They are ideal for helping build a developer and fork moat as anyone can fork the code to pursue their own purpose.
So — should rollups also pursue permissive licenses like a layer-1 blockchain? — it is very easy for someone like myself to champion that all rollups should be fully open-source and permissive, especially when I have not spent several years researching and implementing the rollup project. But, as we will see, it is not as straight-forward as that.
Risk of vampire attacks
A rollup project needs to consider how a permissive license can encourage the developer and fork moat, but inadvertently harm the TVL/user moat.
If a permissively licensed project gets popular and gains fast adoption, then competitors will emerge who will fork the code and attempt to steal the users/TVL from the original project. This is called a vampire attack and the classic example is the Sushiswap vs Uniswap saga.
Briefly, a pseudonym called Chef Nomi forked the Uniswap code, rebranded it as Sushiswap and issued a SUSHI token. The marketing for Sushiswap focused on trying to claim that it was a community-run project and all users should migrate to it, otherwise, the big bad VCs who invested in Uniswap will win. To encourage users to migrate, Sushiswap enabled LPs to farm the newly issued Sushi tokens as a reward.
On hindsight, the vampire attack was partially successful. A significant chunk of the TVL/users did move from Sushiswap to Uniswap to farm the newly issued SUSHI tokens and it forced the hand of Uniswap to issue its own UNI token as a way to fight back.
Interestingly, both projects continued to exist after the Saga as Sushiswap became a real project with differentiated features, but Uniswap was the ultimate victor.
Business Source License
Uniswap, to the best of my knowledge, is the first project to adopt and use a new business license.
It allows the Uniswap V3 code to be openly available for anyone to review and audit, but there are two additional clauses that restrict its use:
Additional use grant. A project can request permission from the developers to deploy the software stack.
Four years expiry. It converts to an openly permissive project and anyone can deploy it without permission.
The motivation for the additional use grant is to twofold:
Discourage vampire attacks. It discourages competitors, or newly spawned initiatives, from forking the code and attacking its developers.
Tie back to the project. It allows the project to be re-deployed on other eco-systems and platforms while ensuring all fees tie back to the projects.
Finally, the four year expiry should help the project get a modest first-mover advantage before competitors can freely use the code against them.
In the case of Uniswap, the business source license makes sense, as it is a project that is deployed onto an eco-system as opposed to being a platform itself. The success of Uniswap is tied to maximising the TVL and trading activity with its smart contract suite compared to forks of its own code.
Rollups as an SDK
If Rollups can be deployed as an SDK, it can fix many of the problems associated with failed Web2 projects like BlockFi, Celsius, FTX, etc, without the need for oppressive and restrictive regulation.
A startup or project can simply take on the role of Sequencer, take user transactions and order them for execution. They can pass the transactions onto a swarm of cyber hornets who will fight each other to execute it.
Most importantly, the startup/project/Sequencer/cyber hornets are not liable. It is solely up to the smart contract bridge, running on a platform like Ethereum, to protect the funds and the off-chain database.
It is not a far-fetched dream either.
There are several startups working to offer Rollups as a Service including Stackr Labs, Artesi and Constellation alongside unnamed mammoth crypto services that have expressed interest in deploying their own rollup eco-system.
In an ideal world — it will be a one-click solution to allow any budding startup to fork a rollup’s code and deploy it for their own needs — but this dream all comes down to the software’s license.
Rollup licenses today
Let’s do a quick scan for some of the leading rollup projects:
Arbitrum → Business Source License
Optimism → MIT License
Polygon Hermez → AGPL-3.0 license
Scroll → Apache License
Other projects like StarkNet and ZKSync remains unclear, although there is evidence they will likely to adopt a permissive license. It is interesting that a majority of rollup projects, except for Arbitrum, have adopted an open and permissive license allowing anyone to fork the code. I suspect the majority’s motivation is due to the perceived pressure to do so and the general ethos of the Ethereum community.
While I typically advocate for a fully permissive license, there is good reason to avoid such a license from the get-go:
Fend against larger projects from taking its code and directly competing with them (“the vampire attack”),
Rollup project can protect itself while it is still a new born and in the process of growing its eco-system,
Competing forks do not feed into the tokenomics of a rollup project.
A good example of the above is the Boba Network that forked the Optimism rollup project. It is a separate instantiation of the code and its very existence has little to no contribution to the OP token. If it were to grow large and significantly overtake the Optimism network — then why would Optimism continue its development?
So, when evaluating a software license for a rollup project, there is a need to strike a balance between allowing projects to simply fork your code and ensuring it feeds back into the eco-system.
I suspect the Arbitrum team adopted the Business Source License as a way to manually manage this trade-off. Both to prevent the rise of immediate competitors using their own code against them and to lay the groundwork for the necessity of a future ARBI token (assuming there will be a token).
However, in my opinion, the Business Source License is not ideal as it empowers the rollup project to gate-keep who can adopt the code. It is a liability for the rollup project as they can make the centralised decision and it is a problem for any startups/projects that want to build for them.
For example, if you are kick-starting a new startup for Rollups as a Service — do you want the operational risk of a rug-pull by building on a rollup project that requires permission to deploy a new instance? And the same rollup project deciding to remove the permission after the fact / refuse to grant further licenses?
Going further — many developers do not want to ask/contact/talk to an external rollup project. This isn’t the Web2 world where business relationships are critically important. If there is a less-developed-but-future-potential rollup that does 90% of the job and it has a permissive license, then developers will pick the underdog 99% of the time.
If rollup projects think they will win the fork moat with a permissioned license and expect developers to reach out before forking their code, then good luck with the nasty surprise when competing rollup projects steam ahead on the fork-moat.
Towards an ecosystem license?
A rollup software license should maximise the TVL of the underlying bridge and all user activity on top of it. If users are transacting outside of the rollup bridge, even if it is the same rollup fork/codebase, then it does not necessarily feedback into the eco-system.
So, this brings us to the question at hand, what about an eco-system license that permits all activity and forks as long as it feeds into the same eco-system?
There are several types of value-capture that can be defined and help return value back to the token holders. Two examples include:
L3 narrative. Allow a project to deploy a fork of the rollup on top of the rollup itself.
For example, StarkEx instances using the SHARP prover (a shared prover for all StarkNet Instances) and perhaps a future where Arbitrum Nova instances are deployed on top of Arbitrum One.
Rent-to-Fork. Allow other projects to deploy a competing fork as long as it pays a percentage of fees back to the eco-system.
For example, 1% of all fees are paid to a smart contract governed by the token holders.
The general theme for an eco-system license is to allow the rollup code to be openly forkable as long as it feeds back into the eco-system at large. Of course, there should not be a requirement for developers to communicate with the rollup project as long as their actions clearly satisfy the license requirement. In fact, the Rollup as a Service startups can help automate that process.
Today — right now — is the right time to really consider what an eco-system license may look like and hopefully it will be superior to both the Business Source License and the various permissive open source licenses.
So, to conclude the article — my argument is simple — it is right for rollup projects to be fearful of vampire attacks and simply releasing projects under permissive licenses may not be in their best interest.
As a community, we need to consider a new ecosystem license that allows anyone to freely fork a rollup codebase as long as it feeds back into the eco-system and its native token.
What that may look like in the end — I do not have an answer for — but it is about the right time to start thinking about it.