New chain policy

As we continue to expand our payment offerings and the onchain economy continues to fracture across chains (L2s, L3s, etc), the cost and complexity of support scales multilinearly (e.g. O(mn)).

As a core piece of infrastructure, our platform’s utility is in demand on many chains. However, not all chains have equal quality and quantity of demand. Nor will all chains be around or be as relevant for as long as others. And rolling back support for a chain is upsetting and painful for both users and partners.

All this means that we need to be thoughtful and judicious about which, when, and how we support chains. For a list of supported chains, check out the Supported chains article.

Our philosophy#

Supporting a chain is not binary and can be accomplished incrementally—deploying the contracts is different than running a subgraph & displaying chain data in our app. Since the contracts require little-to-no maintenance, we have a lower bar for deploying them to a new chain. The opposite is true for our multichain app; there is considerable overhead needed to support a new chain in the app, so our bar must be higher.

Contracts#

We are generally willing to deploy our contracts to new chains for which we have received meaningful interest from users. All contracts and their supported chains can be found in the "Contracts" section of our docs.

As of right now, we do not have a formal process by which a third party can request our contracts to be deployed on a new chain. However, anyone is able to deploy our contracts, and when that happens we hope to be made aware so that we can share with other interested parties.

App#

Supporting chains in our app is a bigger commitment and requires subgraph support, which costs money and is currently dependent on third-party support (Goldsky). It also requires significant engineering time, both upfront and ongoing.

Because of this, we have a much higher bar around adding support for new chains to the app. This is a difficult tradeoff, as the app has become a core piece of infrastructure for many teams' day to day operations.

To this end, there are a few things we're working on or thinking about to increase chain coverage.

1. We have built a stripped down, "headless" version of the app, SplitsKit, which does not require subgraph support. SplitsKit is open source and we encourage interested parties to add more functionality to it over time.
2. Longer term, we're are considering alternative splitter structures that make it easier to support new chains. Again, this will require tradeoffs (e.g., more onchain data means more expensive operations) and time to get right.

Conclusion#

This is a challenging topic, both for the community at large and for us internally. Having rock solid company values makes internal decision making easier.

Focus is a core company value. To us this means: if we try to do everything, we'll accomplish nothing. We must be willing to say "no" thousands of times so that we can say "yes" to what is important, meaningful, and aligned with our mission. Our mission is to help people take control of their earnings.