Update on Chain selection

Update on Chain Selection

As our roadmap states, the first thing we want to do is find a “better” blockchain for the first active home of DSNP other than Ethereum. Ethereum has been a great chain for experimenting and building version 1 of the DSNP upon. The tooling and documentation is mature and we had hoped Ethereum might find a way to reduce costs before we wanted to launch (looking at you Eth2). Either way building out the DSNP on Ethereum was a great baseline.

So Ethereum is expensive, both in terms of fiat and environmental costs. That leaves us with a need to build DSNP on a different chain. Besides just a new chain, we also hope to start building toward multi-chain, and understanding how DSNP would look on another chain gives us a chance to look toward our eventual goal of being multi-chain.

The criteria and feature set for a non-Ethereum chain are a set of requirements and tradeoffs. Here are the most important (but not all).


  1. Decentralized disinterested nodes - Decentralized can mean different things to different people, but one of the key features for us is that the nodes are not interested in the messages they are relaying and adding to the chain.
  2. Cost (In fiat and environmental) - Aka not proof-of-work, or at least not as we have seen it so far, but also watching out for chains that will fail this test when they scale.
  3. Open source - For security, flexibility, and long term sustainability.
  4. Mainnet - While we might be willing to choose a chain who has a mainnet about to go live, having a state that we can build on is critical.
  5. Responsive and inclusive developer communities - How do the developer community handle questions from n00bs? Are they responsive, kind, and respectful?


  • Storage guarantees - Data existing forever might not be needed for everything, and user control is great, but also not great if data you want can disappear or be unavailable just because a node went down or no one has accessed it in a while.
  • Chain security - What security guarantees and assumptions are there for a given chain?
  • Chain maturity - How long has the chain been running? Do we have a good number of nodes? Is there money to continue to improve and maintain it?
  • Token accessibility - Can most people get the token needed to do things on the mainnet?
  • Funding Source / Node Locations - Some groups may be opposed to the principles of DSNP.

Nice to Haves

  • Good documentation - It’s hard, but so nice.
  • Independent wallet support - Are there other wallets out there other than the one the chain directly built?
  • SDK / Libraries - We have a lot of code to write, and having less to write is good.

When looking at a long list of chains (see the end of the post) we found most chains fall into one or more of these categories:

  • Ethereum Replacements
    • These chains want to be the #1 replacement for ethereum
  • Sharding Focused
    • Chains that focus heavily on sharding data
  • Ethereum Layer 2
    • Chains that rollup or otherwise anchor to Ethereum
  • Blockchain of Blockchains
    • Hubs and parachains
  • Proof of Authority Chains
    • Ones that fall here break our criteria of decentralization
  • Unique
    • Some chains just don’t really fit into a category or would just be a category of one

Chains in Alphabetical Order

Here is a list of most of the chains we are at least looking into a bit. Several of these can likely be excluded quickly based on our core criteria, but I’m still listing them for completeness.

We hope to have some more updates soon, likely on a list of chains that failed to pass initial criteria (some of which you might be able to guess). If you have thoughts, please add them! The blockchain space is moving so quickly, this chain list is sure to be incomplete. What criteria would you say was most important?


In my opinion, the most important criteria is scalability. I’m still not even convinced these types of technology can handle web2 scale yet.

Sharding is definitely needed no matter what, I think the real question is DAG vs linkedin-list.

ETH is by far the leader in terms of developer mind-share so it will be tough to displace. If ETH2 works I don’t know if any other chains will really matter. Better to just wait a few months and see. https://zksync.io and other L2 solutions are looking very promising.

If DAGs are the solution I would add these 2 projects to your list:



Another wild card is https://koinos.io - they are doing something totally unique as far as I’m aware. Their architecture allows for the chain to be dynamically updated via smart-contracts, so there is no ‘hard-forking’.

1 Like

Thanks for your thoughts! Here are some back…

Scalability is hard, but I think about the speed of Bitcoin compared to Solana for example, and I think (hope?) that we are getting better. Blockchain is still young.

Re: Sharding
The largest issues in sharding (for DSNP) that I have seen is discoverability and accessibility. How do I know new things exist and how do I access them. Some systems have solved discoverability without accessibility (A great example of this are torrents. You might know of a torrent, but getting all of the resulting file is hard) Other systems have solved accessibility without discoverability (Thinking of Mastadon and the Fediverse. If you know about something, you can (likely) access it, but knowing about it can be difficult.)

Re: L2
I haven’t yet found L2 super useful for DSNP yet (or at least not how many of them work). Financial data is highly compressible. So rollups and such make sense (payment channel rollups are a great example. Final balances are all you /have/ to have). Rolling up other less compressible data doesn’t gain as much, but I keep hoping and looking at new ones. I’ll add zksync.io to our list of L2s to look at.

Re: DAGs/Koinos
I’ll add those three chains to our list. DAGs are interesting, but I think their newness (the specific chains not DAGs in general) is a disadvantage in the chain maturity tradeoff. Any idea how IOTA or Constellation would fair on the other requirements and tradeoffs? Specifically curious about storage guarantees…

Hi everyone. I’ve been in blockchain since 2016 but am new here. I would add to the list www.near.org and www.radixdlt.com. No one wants a longer list, but I think those two may meet the criteria.

1 Like

Hi @davidsiegel! I have heard of near, but not radix. We’ll add them to the list. Any tips from you as to what makes them standout that we should look for?

I think they meet your criteria, that’s all. The choices are now pretty bewildering. I always advocate not using blockchain except for the very few bits that really need it, so if you design things right, swapping a blockchain out shouldn’t be the end of the world. I think most of it can just be open-source code that people use and hold their own private keys to their assets. I’ve been around this loop a few times - the more you put on chain, the more time it takes, the more difficult the UI becomes, and the less you can test with users.

Why are you even considering a blockchain?
My social graph is “mine” and between me and the people I talk to. I don’t need a blockchain to do it and i don’t want my information about who I am connected to on an Immutable ledger. Its nobody’s business but mine.
Why not look at a protocol like DIDComm to support connections.

We definitely won’t be putting everything on blockchain, and content such as posts, graph changes and profiles is not intended go on a blockchain. Swapping out blockchains isn’t a piece of cake, but it’s kind of the least of the reasons not to put that content on it. For one thing it’s next to impossible to put that data on some chains and for another, it’s would get unbearably expensive. On the testnet, the only thing that is posted at all on chain is the existence of a unique registration ID and associated handles (as part of account state, which is in fact mutable**), and the announcement of URLs of batches of stored, off-chain Activity Pub data of different types. That batch can be deleted, and so can the content that the ActivityPubs in the batch points to.

Not the least reason is it makes it impossible to comply with right to be forgotten laws, or to remove illegal content. It also makes important privacy choices tougher. One primary purpose of using a chain is as a trustless, decentralized* way of establishing a digital presence and being able to control it regardless of what app you use to access platform, and the next is for discoverability of others and their content that you don’t already know about. Finally it gives a way to verify that off-chain content is stored as claimed.

It’s also important to know that not all blockchains are like Bitcoin or even Ethereum. Not everything “on chain” is immutable and not everything persists forever, and not even contracts are forever on every blockchain. On Algorand, for example, you can completely delete a smart contract and any state it has stored with an account. The only part of a blockchain that needs to persist and be immutable is the actual block data, that is, whatever is on the ledger. Even that can get garbage collected. i.e. basically forgotten depending on the chain and how long ago the block was created.

I would encourage anyone who is unfamiliar with this project to read at least the top levels of the DSNP Spec first, where many of these very reasonable thoughts and questions might be addressed already.

** one can make a strong, privacy-based argument for not even storing handles.

  • in the sense of the data living on many servers that are controlled by unrelated entities

Who made this design and how?
It just doesn’t seem realistic.

Did you talk to actual community organizers about what they want?

Did anybody do a systematic cost analysis, and if so, is there a pointer to that analysis somewhere?

Something along the lines of:

  • assume 1 million concurrent users
  • 1 post / week / user, 2 comments / day / user, 2 likes / day / user, … (I made those numbers up – use some reasonable assumptions based on usage stats from typical social media services)

And then: therefore the number of blockchain transactions per user per month is … and that is roughly … USD per month per user in transaction costs for various block chains.

Which will be paid for by … and which thus makes apps built on this protocol viable for application areas / verticals / … but not for applications areas / verticals / …

Costs are interesting to model. The primary important piece to remember is that due to Batching, the chain costs do not scale linearly. So 5 posts can have the same chain cost as 100 posts.

In fact costs improves somewhat with scale as it is the cost of a transaction divided by the number of posts the batch contains.

While we are (as this thread is mostly about) moving away from an Ethereum solution and cost profile, the publishing contract on Rinkeby has transactions that you could price out (on Ethereum) for creating posts and other content. https://rinkeby.etherscan.io/address/0xeF7B5d418128fB8C1645Dd31270BE2cCAF9015e4

In addition to different applications directly batch publishing, it is likely that we and others would provide batching services to amortize the cost per interaction even lower.

Thanks for taking the time and engaging with us. We value your input.

To answer your question on design and involved team members, it would help if you could be a bit more specific about these points.

To answer your second question " Did you talk to actual community organizers about what they want?"

Yes! We are really excited to engage with different communities. We have made an effort to engage with both technical and non technical communities.

Last month we organized an event called The Summit for Decentralized Infrastructure, which brought thoughtful leaders and a diverse discussion on identity. Our goal was to take as much input and questions from the community and foster deeper connections and increased collaboration among people working on decentralized social networking, identity, and storage.

This Summit took place as an adjunct to Unfinished Live where we brought speakers from across different disciplines and explored the possibilities of a decentralized web. We got a chance to hear and learn from a diverse group of communities .

It was also great learning more about identity at the IIW event… We hope to have more engaged discussions and meaningful conversations centered around identity.

We try our best to be an open and welcoming to different inputs with the limited resources we have.
We know that we can always do better but bear with us as we adopt different conventions and ideas.

You asked,“What criteria would you say was most important?”

If you are going to make a true utility, it MUST be with chains as they were meant to be, chains of unique blocks of code. There is just so many ways to get there that there is no excuse to not have proper chain tech, “unique”. Chaining of info is driven through blocks of code that may or may not react. Storage of data is not an option, due to privacy issues.

Don’t geek this into some whacked out system of mud designed to consume energy. Decentralize. Make everything matter. Make everything a fact. The storage comes in as people get to build on the last chains delivery and use its affect, not data storage. The chain Must have purpose, not just growth capacity, anyone can do that. Or else you are just building another, dime a dozen, privately owned data center for those who are “allowed.”

A unique chain is personal by definition, not full of personal data.