Subscan ought to change its business model or be replaced

Ecosystem
1

Subscan is a treasury-funded project, but charges parachain teams tens of thousands of dollars to add support for their chain. This isn’t a good thing for the ecosystem & will only guarantee that it will never be the all-in-one block explorer for the ecosystem, which is what we actually need, as there will likely always be a project where paying such costs are not feasible.

Subscan should provide this as a free service to parachains, which is then compensated by the Subscan team billing the treasury afterward. This will help bring further oversight & scrutiny on the Subscan team for the rates they charge as well and guarantee we end up with a block explorer that is actually for the whole ecosystem. This should be seen as a common-good ecosystem service, with infrastructure upkeep costs

Otherwise, I believe that funding support for Subscan should ultimately die down & instead be focused on funding a new team/explorer that can operate as recommended above. The last billing estimate shared with me (by another parachain team currently on Subscan) was around $50k (they paid), which they informed me had scaled down to $30k (a new project would have to pay). It doesn’t make sense to charge parachain teams this amount of money when other platforms aren’t.

There are projects such as https://polkaholic.io/ which validate that it doesn’t cost as much as what is charged to provide the infrastructure for such an explorer. It appears that a proper user interface is what needs to be funded here & then monthly upkeep. If I am correct, then with this, we could provide an ecosystem-wide block explorer while also saving teams (100% saving) & the Polkadot treasury (difference between Subscan payments & the costs of more efficient maintenance) money.

Whether it is Subscan under a different business model or a new project such as polkaholic, we need an ecosystem-wide block explorer. At the time of this post, the number of parachains not supported by Subscan is larger than the number of parachains that are supported.

In the event Subscan fails to do this & and fails at being an ecosystem-wide block explorer, then the treasury should instead fund a project that is, and replace the Subscan links in the Substrate Dev Console (polkadot.js app) with a new explorer that can/does in order to better promote that block explorer.

I’m looking forward to hopefully sparking a serious & eventually fruitful discussion with this post.

6 Likes
2

Thank you for your post and your interest in Subscan, I understand your concerns regarding Subscan’s pricing model. I appreciate your feedback and would like to address your concerns.

Firstly, we would like to clarify that Subscan has a free and open-source version of the explorer - Subscan essentials, which has been sponsored by W3F and actively maintained by our team for the past three years. And we recently released Customizable Data Dashboard Toolset, it will be more convenient to add custom functions to the explorer.

Regarding explorer-related funding sources, we emphasize that we only request treasury funding for the maintenance of Polkadot, Kusama, their testnets, and public chains. The costs cover only machine and security services, and we have not included any human costs or rent expenses in our calculations until 2023, which were previously borne by the Subscan team. For some proposals that include development costs, such as multi-signature tools, they are completely open source and free to use.

We believe that it is the responsibility of each parachain team to select and provide infrastructure to their users. Each project is an independent entity and should not solely rely on Polkadot’s funding to obtain explorer services. They can use open-source code to build their own explorer or choose to pay for integration into Subscan[.io] or other explorer service providers to obtain more high-value-added features based on their needs.

Regarding the pricing issue you mentioned, we evaluate and provide a separate quotation for each network, so the price is not applicable to all networks. Furthermore, during market downturns, we are generous in reducing profits to benefit more ecological projects.

Subscan[.io] is a commercial project, and our vision is to provide a comprehensive explorer service for the Substrate ecosystem. We have maintained weekly updates for the past three years, and we believe this is well recognized by the community. The reason we charge fees is to ensure the sustainable operation of the project and to safeguard the basic rights of our employees, which is entirely reasonable.

In conclusion, we share the same vision of an all-in-one block explorer for the ecosystem, but I believe that it should not be achieved simply by providing Subscan[.io] as a free service to parachains. Furthermore, we do not think that the Polkadot treasury should bear all the infrastructure costs of every parachain. We welcome further discussion on this matter to benefit the entire ecosystem.

Thank you again for your feedback and interest in Subscan. We are always dedicated to offering a dependable, visually appealing, and efficient explorer service for the Substrate ecosystem, and community usage and feedback are very welcome!

Yakio | Subscan

1 Like
3

Hi @XCAstronaut,

Thank you so much for your feedback!

Full responses are still under review, system notification reminds me that it will be posted public later. In order to ensure real-time performance, my point of view is described here in advance, welcome to discuss!

Yakio ｜ Subscan

2 Likes
4

We strongly agree that the ecosystem deserves ecosystem-wide “multichain block explorers” and that a SaaS model on new parachains yields less than 100% coverage. We believe Treasury can and should fund multiple ecosystem wide indexers and index 100% of all parachain activity, covering the tail of parachains that do not have archive nodes. I believe the parent-child bounty system can be used to achieve this objective. It would be wonderful to have parent curators be parachains and child bounties for { indexing, archive node (esp the “tail”), UI development (for console.polkadot.network and explorer.polkadot.network) }.

polkadot.js apps has both subscan and polkaholic links (and others), but no Third-Party APIs (e.g. there is no “search bar” to search for an txHash or account there). We proved to ourselves that it is straightforward to wire up polkadot.js to Polkaholic.io APIs (and probably subscan and other APIs), but: jacogr’s belief (along with many others) is that polkadot.js should NOT read from third party APIs by default – see this issue. I think we should respect that purist belief while pursuing a solution for the everyday pragmatist.

My recommendation to address the purists vs pragmatist is that https://console.polkadot.network to house polkadot.js apps with Third-Party APIs added, where users should be able to access a waterfall of Indexer API with one click and have it stick. There are things missing like “what is the USD/DOT/KSM price of X at this time”, calls to access XCM GAR + substrate-etl, Asset Transfer API, among others. I suspect a serious number of purists will start using https://console.polkadot.network and become pragmatists.

In terms of costs, I don’t think having 70 chains*50K=$3.5MM/yr would be appropriate for each and every indexer, but I do think that 3 indexers (not 1) put together totaling that would be fair – you do need around 4-6 people from each of those 3 indexers to do a respectable job. The bounty structure needs to support growth, as 70-75 chains becomes 125-150 over the next 18 months.

These same set of APIs could power a more grandma friendly https://explorer.polkadot.network that takes out as much of https://console.polkadot.network swiss army knife complexity as possible and feels like it was built by the same team that did https://staking.polkadot.network. This should only be another child bounty and solely be about front-end engineering.

The danger in systematically proposing that all ecosystem-wide solutions live at https://xyz.polkadot.network is that it inadvertently suffocate other solutions that also aim to deliver xyz. I’m glad polkadot.js.org lived where it did so that newcomers had some room to breathe. Users always have the choice to do everything, and there is something about https://xyz.polkadot.network that is one step away from that.

While Etherscan made Web3 UX norms something like { “ok, submit tx in your dapp” => “check what happens on etherscan.io” => repeat } its not the only way: dapps and/or wallets could embed the functionality of the multichain block explorer. A function like “DOTSwap” or “AssetTransfer” might deserve to be a feature amidst all that, that really requires deviating from the “ok, select your RPC node” starting point that polkadot.js apps assumed was axiomatic. The slates are clean enough that we can rethink this a bit.

1 Like
5

Hey @yakio, thank you for the prompt & detailed reply!

Regarding explorer-related funding sources…

I would like to start by first underscoring that my original post isn’t intended to be an attack on the integrity or work history of the Subscan team. The purpose of this post isn’t to raise any concern over the billing rates or sums requested by the Subscan team & provided by the Polkadot treasury in the past. As far as I am concerned, you have delivered well on these. However, as I mentioned, that is not the reason for my concern.

I believe that a common, well-recognized, & easily accessible multichain block explorer is absolutely essential for the long-term adoption, growth, and success of the Polkadot ecosystem. Unfortunately, while your products are great, I believe that your current business model is very unhealthy for the ecosystem. While it is well-recognized, without being common (by lacking support for most parachains) and easily accessible (re: costs), I would argue that the heightened recognition only doubles down on the greater issue here.

We believe that it is the responsibility of each parachain team to select and provide infrastructure to their users. Each project is an independent entity and should not solely rely on Polkadot’s funding to obtain explorer services.*

I agree & disagree with these points. Just like the United States is one country comprised of many states, Polkadot is one ecosystem comprised of many chains. When determining what is considered the responsibility of the federal vs state governments, a common question to answer is whether the topic at hand involves an activity that occurs across state lines (in more than one state). If it doesn’t, then the responsibility is usually delegated to the state governments to handle. If it does, such as interstate commerce, then the responsibility is placed on the federal government. I think that the same philosophy can & should be applied here.

Cross-chain transactions are akin to interstate commerce. Especially with XCMv3 coming in the more immediate future, we’re about to see all of the various parachains operate & function together as a single ecosystem. Imagine: you’re driving on a highway & then suddenly you hit a brick wall as you attempt to cross state lines. This is the same experience currently being provided to the Polkadot community & explorers of the ecosystem.

Forcing the states to pay for their highways would have saved the federal government money in the short term; however, this also would have hurt many states (bolstering rich states & disenfranchising poor ones) & cause the federal government to lose a much greater sum in long-term revenue.

Our blockchains may be interoperable, but our users’ experiences are quite fractured.

Furthermore, during market downturns, we are generous in reducing profits to benefit more ecological projects.

I hope this doesn’t come off as a bit of a snarky comment, but if you are able to be so generous when reducing profits, then maybe your profits are a bit too generous in the first place. The way I see it is that the same service is being provided across parachains, and while I didn’t mean to expose information you try to keep private, the fact that these prices are far from uniform should be of great concern as nobody can verify whether they are being given a fair deal or reaped for profit.

The information explained above regarding the significance of cross-chain commerce combined with the revelations of price inconsistencies are the reasons why I believe that either a different business model should be prioritized by the Subscan team -or- a different block explorer should be prioritized by the Polkadot community. No matter which route is taken, it will ensure that the ecosystem is provided with this basic & fundamental architecture. Furthermore, it will ensure that the providing team has some sense of scrutiny placed on them to help ensure fair & transparent pricing.

6

@yakio, I am curious, but in the event that the Polkadot treasury chose to fund the integration services for parachains, would you accept this opportunity? If so, then what is currently stopping you from supporting such a treasury effort? Otherwise, why would you choose not to take such a business deal?

I would very much like to see Subscan become the multichain block explorer that this ecosystem needs; however, it has to be an ecosystem-subsidized service to ensure this happens, at least from how I see things.

7

Hi @XCAstronaut Thanks a lot for your reply, it’s a great topic. Please believe that on the basis of ensuring project cost and stable operation, no one wants to expand more users than me, so that more parachains can enjoy the Subscan explorer service at low cost. It is my sincere belief that our goals are aligned, and I would be delighted to engage in a friendly and constructive discussion on this topic.

First of all, regarding cross-chain transactions, Subscan will continue to serve all Parachains, even if these Parachains have not subscribed to Subscan’s explorer service.

It can be seen from here that the cross-chain transactions supported by Subscan cover all parachains. And we will actively support XCM V3, which is a feature I am very concerned about and looking forward to!

However, supporting cross-chain transactions is different from providing a complete explorer service. The following content is only related to Subscan’s explorer service.

Regarding the pricing of Subscan, it is determined by adding a certain profit margin to the actual cost. This principle is based on the simplest rule of market economy. For instance, when a dealer sells goods in a market, if the price of an item is perceived as too high by most consumers, they will refrain from buying it, which will push the dealer to lower costs and profits in order to attract more customers. Conversely, if the supply of a product is limited due to production constraints, price increases may be a viable business strategy. And we have been actively adjusting prices according to market changes.

Every team must set aside funds to manage potential risks and guarantee the uninterrupted operation of the project, and Subscan is no exception. Subscan has consistently maintained a competitive advantage in the industry, which is closely related to the costs we have incurred. It would be extremely irresponsible to make conjectures and influence public opinion without comprehending the resources and expenses that Subscan has invested.

I am curious, but in the event that the Polkadot treasury chose to fund the integration services for parachains, would you accept this opportunity? If so, then what is currently stopping you from supporting such a treasury effort? Otherwise, why would you choose not to take such a business deal?

To clarify, I support that the expenses of non-public parachains should be borne by themselves. This is because these parachains are independent entities, and it is more reasonable to use their own treasury to cover these costs rather than relying on the Polkadot treasury. Furthermore, if payment of infrastructure costs by the Polkadot treasury for each project, regardless of quality or legitimacy, may result in a waste of resources. Therefore, a review process is necessary to ensure responsible allocation of funds.

For the public parachain, since it has no source of income, it is reasonable to pay this fee through the polkadot treasury, and Subscan will provide it with a very large discount as always. Of course, this is just my opinion, and I’m not a council member, so my opinion is not decisive.

As a public parachain, Ecointer once reimbursed the bills from Subscan in the polkadot treasury and was approved, and we happily accepted the funds. If any project considers applying for funding using the same method, Subscan will fully cooperate in providing invoices and billing details. But whether the treasury proposal is passed will be decided by the community or council members.

For networks with limited budget due to the early stage of the project, we are looking for some solutions. We will fully listen to the suggestions of the community, let’s find a better way to benefit more projects together.

8

I would like to suggest a somewhat different approach to this than the binary “Polkadot Treasury pays” vs. “each parachain pays” model for services (not just Subscan) where there is likely some common cost for the provider and then a decreasing marginal cost for each additional parachain. I suggest that this forms part of the future of the Parachain Technical Fellowship (PTF) and the future of the Treasury.

The PTF would be another instance of the Ranked Collective pallet in Polkadot’s Collectives parachain. Gav mentioned this idea at Sub0 last year. Rather than the existing Technical Fellowship, which is focused on assembling a group of experts in the Polkadot protocol, the Parachain Technical Fellowship would assemble experts in parachain development and operation. Like other collectives, when coupled with an instance of the Referenda pallet, the PTF could control a number of pre-defined origins.

One (or several) of those origins could control an account (on multiple chains) corresponding to another instance of the Treasury pallet (the logic of which would sit alongside the PTF). Of course, by default most or all new DOT would enter the “main” Treasury, but collectives could have their own treasuries too. The PTF could make one (probably quite substantial) proposal to the main Polkadot Treasury to fund the PTF Treasury. Then, the PTF Treasury’s SpendOrigin would correspond to some rank-weighted quorum/approval of the PTF, and could decide to fund initiatives that benefit all parachains somewhat equally or address common pain points for parachain developers.

There are many more applications of this pattern. For example, the Ambassador Program could also have an instance of the Treasury pallet, and request a yearly budget from the main Treasury for things like events. Then, high ranking Ambassadors can approve event spending, instead of coming to the main Treasury every time someone wants to host a meetup.

For many collectives, I imagine they will manifest as a bundle of Ranked Collective, Referenda, and Treasury pallets. Each collective’s origin can control its own Treasury, make spending proposals to the main Treasury, and perhaps have certain other governing privileges (e.g. Technical Fellowship having WhitelistOrigin, and PTF having an origin that can unbrick parachains).

Using this model, the PTF could fund infrastructure that is common to all parachains, and decide how to allocate its Treasury, while still leaving individual parachains the freedom to supplement that if they want specific additional services or something custom.

6 Likes
9

The IBP (Infrastructure Builders Program) stands ready to include indexer endpoints as part of it’s mission if it’s desirable for the community to have those services. Our mission statement is to provide core infrastructure services in a more decentralized and fault tolerant way. Indexer nodes would be part of that mission.

I don’t know how much of this cost incurred by subscan is related to tooling, and how much of it is infrastructure driven, but certainly the infrastructure side we can handle.

4 Likes
10

The overall architecture of this system sounds fantastic, to be honest. Thank you for the awesome breakdown here, @joepetrowski! This is (more/less) the exact functionality that we have realized with our multisig solution we are beginning to ship out for the ecosystem this week & over the next few weeks, which was funded by the Kusama treasury - essentially allowing dynamic multisigs to govern themselves as DAOs, have the ability to feature customizable roles & permissions, and the ability for treasuries & sub-treasuries to be enacted to realize a more organized & optimized digital organization. In general, I am a fan of this approach.

The main question I have is:

  1. What is the envisioned timeline to see something like this come to fruition?

  • If this will take 3 months or longer to enact, then while we should keep this approach in the back of our minds for the future, I believe it’s important that we address some things more immediately in the short term, such as what is promoted across the ecosystem.

  • If this will take 6 months or longer to enact, then I believe we should keep this approach in the back of our minds for the future while also pursuing a treasury solution in the more immediate future.

The only concern I have is addressing how new projects will be able to access this service in the future. Will they need to provide capital to the treasury and will this be an accessible cost for a team that doesn’t pursue the venture capital route? If this is unattainable by a few (followed by a growing number of) teams, then we may fund ourselves in a better position than we are in now but still facing the same general problem we are facing regarding the realization of a proper & all-encompassing block explorer for the ecosystem.

We need to assume (and hope that it is possible) that projects that onboard to the relay as parachains will sometimes be minimally bankrolled projects, and that Polkadot will house parachains that come from both big venture capital endeavors & from humble beginnings. We should also assume that there will be parachains with sound & meaningful tech, which does not always equate to a project having a lot of cash on hand or even a token of listed value to provide towards this.

I just want to avoid an instance where we overthink the solution here. I think that the treasury & how it is managed could & should be restructured altogether; however, if this is something that will take several months to realize, then I would argue that this isn’t a solution to the immediate topic as much as it could be for a topic focusing on the general management & organization of the treasury.

On the other hand, if what you propose will be a part of the more immediate future, then I think this could be the right approach, pending fruitful discussions around how organized treasury funds should be budgeted & facilitated.

If the vision is that Polkadot will consist of parachains just as commonly as Ethereum consists of smart contracts, and that the UX/DX will be the same (if not better), then this is a specific issue that I strongly believe needs to be addressed. Otherwise, it’s just another thing that builders have to worry about in this ecosystem.

11

Unfortunately, this didn’t answer my question. I understand that you are not in favor of a treasury funded effort; however, I feel I have already expressed why your current practice guarantees an inability to realize a future where Subscan is the one-stop shop block explorer for the ecosystem.

What I would like to know is, if (whether against your beliefs or not) the Polkadot treasury pursued a path where it ultimately covered the costs for block explorer integration services for its parachains, would Subscan work to be the block explorer that services parachains under such a decision?

It’s a very straightforward, “yes” or “no” answer that would be needed. The assumption is that how this gets funded is out of your control, and instead, you are faced with either being funded by the treasury to service all parachains -or- ignoring this decision & instead continuing along your current model.

There is no right or wrong answer; however, I would argue that the latter helps underscore the argument that the broader ecosystem, and especially those at Parity, should be very aware not to promote Subscan as its continued promotion will only serve to conflict with the block explorer that actually does end up servicing the whole ecosystem.

12

I don’t know if you are asking me or anyone in particular, but it is the Parachain Technical Fellowship we’re talking about here. The technical capacity for fellowships obviously exists based on the existence of the protocol Technical Fellowship.

The timeline is whenever someone writes a vision for how this group will be structured, what its role in the ecosystem will be, what kinds of powers it will ask governance to be handed over to it (e.g. change force_set_current_code from Root origin to PTF origin), who qualifies for membership and promotion, how to seed the group, etc. Parachain teams obviously know best what challenges parachain teams face. I don’t think “wait for Parity to do it” is the right strategy.

Gav wrote the forum post for the Technical Fellowship with those details in September 2022, and the Tech Committee initialized the group in November. Add in the time to write up the manifesto and seeding process ahead of that and you can get a good timeline. 3 months seems reasonable.

I’m not sure what you mean by “access this service”. Do you mean join the PTF? Entry requirements should be part of the manifesto. “Buy your way in” seems like a bad approach IMO. Or do you mean access funds under the PTF treasury? Of course, simple referendum from the PTF to approve a spend. Or do you mean fund the PTF treasury? I’d envision the PTF making a funding proposal itself to the main Treasury. Of course other chains can add assets to the PTF treasury if they want.

“Replacing Subscan” does not seem like a “several months” solution either :).

1 Like
13

@XCAstronaut I think it would be great if you drafted a manifesto for PTF. One key principle that I would hope your manifesto to contain in a rethink is this:

Parachains see the UX / Tooling / Infrastructure teams (e.g. multichain block explorers, dapps) as being their valued partners, with the same incentives as the parachains core teams

The SaaS business model that you are arguing against sees the world as a zero-sum game: “every $ they gain, is a $ we lost”. This is true for $/hour type models that dominate UX / Tooling / Infrastructure Treasury proposals, and continues into the Polkadot Payroll. Nothing wrong with paying teams like dentists in the Polkadot Payroll. But you end up with a hostile dynamic between someone trying to honestly protect the Treasury’s fixed-sized looking pot against “unjustified” profits, saying things like “250K DOT? That’s crazy, right?” and someone else trying to build a Web3 business and feeling suffocated.

But there are other ways:

  • Parachains can just outright set aside a portion of their native tokens for their partners.
  • Astar has the exemplary model with its Dapps Staking program. Our team might only make $6/day today, but there are many other teams that actually making enough to feed 4-6 engineers, and if we do something decent, the program enables us to do the same thing. In particular, it has the community not picking a single winner, but the capacity to have new teams enter and old teams exit the system because they do or do not provide value.

We did NOT arrive into the Web3 ecosystem to be paid like dentists, fighting for a portion of a $3.5MM/yr market or earning $90/hr. We came here to build infinitely scalable businesses, part of Web3’s “on-chain industries”. When I look at parachain teams, I see entrepreneurs trying to build $1B market businesses. I think their partners deserve to see that upside.

If I am waking up today to build a WASM Contracts Explorer/… (or whatever your parachain needs) for Astar/… because Astar/… actually created a real mechanism to go from $6/day to $6K/day in a new market of WASM Contracts, then Astar’s dApps Staking got the incentives right. So I strongly recommend your new PTF look at the question of “how do we build Web3 on-industries where everyone’s incentives are aligned?”

The wrong answer (in the long-term) is: A fixed DOT/X budget from the Treasury (or PTF) to index 70-200 chains. It might work for a little while, but it is wrong in the long-term because it does NOT motivate teams to build the UX / Tooling / Infrastructure to get at the infinitely scalable business. It says “no matter what these teams do, the most these teams will ever be able to get is whatever this fixed DOT/X budget is”. In particular, it doesn’t lead to competition, which leads to a form of innovation stagnation that is the exact opposite of what Substrate enables.

The right answer will have the team on the exact same page as whatever it is your dev/marketing/tokenholders are motivated by. I think its your parachain token value, but maybe you will have a better idea.

There are legions of people in this industry who find Apple/Google’s 30% “tax” on the ecosystem excessive (Netflix/Epic … continuing to omg, bloody NFTs). But when you look at a high level, Apple + Google enabled Web2 businesses to build extremely large businesses (look at your phone’s apps and ask how Web3 businesses will be as large as the businesses who built the $-earning apps in those ecosystems) – a serious # of them motivated by “70% of infinity”. So even if you hate the size of 30%, “70% of Infinity” is a LOT bigger than $3.5MM/yr, and enable millions of people to go from earning $6/day to (at least for the top 0.01%) billions of dollars a year.

Infinite wealth should be shared with valued partners.

1 Like
14

Thanks for the reply, Joe!

Disclaimer: I believe this conversation should prioritize discussion focused on 1) the significance of a multichain block explorer & whether (the case I am making, that) such an explorer is integral to the broader success of Polkadot, 2) whether Polkadot as a project should be promoting a block explorer that has an opaque business model & lacks support for (a majority of) the broader ecosystem or whether that project should/would consider changing its current business model & practices, and 3) in the end, depending on the general consensus around the first two matters, what block explorer (if any currently existing one) should be promoted & how it should be supported.

Regarding the PTF, I am beginning to think that its presence in this discussion is distracting from the more foundational topics here. While I understand that the topic of this conversation may be a good example of a matter that could be handled by an initiative such as the PTF, I think a separate public discussion around the PTF would be more suitable than making its case here.

The reason I say this is because the PTF at this point does not exist and is a proposition for parachain teams to uptake, which distracts from the underlying argument that a multichain block explorer should be seen as common-good & required infrastructure for the success of Polkadot. Regardless of whether or not the PTF comes to fruition, the Polkadot ecosystem as a whole will suffer without a multichain block explorer.

I agree, but I don’t think that the PTF is the right answer, at least for now or in the immediate future. Builders in this ecosystem need fewer hurdles when building in this ecosystem, not more work to do (such as setting up & then participating in the PTF) alongside the work that is already involved with building in this ecosystem. The topic of a multichain block explorer should be understood as a problem that Polkadot needs to solve, not as a common feature that parachains should pursue.

The service being block explorer support. The PTF misses the greater issue here. A block explorer is something that a live parachain ought to have available on day 1 of launch, regardless of whether they are a part of the PTF. It’s also something that one would assume a parachain needs prior to their token having a sense of value, so the PTF would likely need to cover the costs not just of their current members, but for parachains that may or may not ever join or contribute to the PTF, which is the flaw in this solution. Otherwise, there is likely to be a gap between a parachain going live & block explorer support. Unless Polkadot desires to become an oligarchy seeded by the wealthy few, I think a different approach is needed here.

Why not? I’ll reiterate that I would much rather Subscan be open to a more transparent billing process provided by the treasury. Nonetheless, this doesn’t need to be overly complicated.

Step one would be to avoid promoting them on social media or including Subscan links in any public or community-gated settings, primarily social media. Step two could involve reaching out to current projects that already provide block explorer support to all parachains by default & discussing if they would be interested in a bounty to cover costs to develop a more modern UI. Step 3 is, after development (which should take about 2 months if not sooner, minus testing), to start promoting that newly improved block explorer & work on promoting awareness of it.

Step 1 can be more immediately acted on in order to stop increasing the problem where the most recognized block explorer of the Polkadot ecosystem is also one that supports less than half of the parachains in the ecosystem (considering there are other platforms that already support every parachain).

“Replacing Subscan” isn’t a “several months” process unless we make it one.

To underscore the significance of making this a more inviting ecosystem to build in, I would like to highlight that the crowdloan auction schedule was just engineered by Parity to be more artificially competitive because the current rate of demand isn’t keeping up with the supply.

If demand is low, we should be looking at ways to make this an ecosystem where it is easier to build & deploy. The tactic mentioned in the preceding paragraph did the opposite. Similarly, when addressing the concern & need for an ecosystem-wide block explorer, pushing the solution off as dependent on the formation of the PTF, this isn’t making anyone’s lives easier to build in the ecosystem. On the contrary, it just adds more work.

This isn’t a matter of whether or not parachains need a block explorer (where they could all, for example, technically end up with their own unique block explorer platforms) for their own sakes. This is a matter of Polkadot needing a clearly known multichain block explorer for the sake of Polakdot itself. Otherwise, both in terms of UX & DX, we aren’t providing a better experience than if somebody were to build elsewhere, which IMO, should be seen as unacceptable.

15

Yeah that’s fair, will drop the PTF from this thread, except one more thing :).

I really hope that this is not what the PTF would become: An exclusive club that gets special services for their own parachains. It should be a group of established experts in parachain development and deployment that can prioritize making the experience of building a parachain on Polkadot better for everyone.

This is quite a bold accusation. Since I was involved in making the schedule and proposed it myself, I’d be rather interested in any evidence you have to support it.

17

I want to restrain from diving down this topic focus too much, at least within this specific discussion; however, I will underscore that my original statement isn’t intended to be perceived as a “bold accusation” as much as I believed to be stating a common-sense conclusion. In this scenario, I would provide the same evidence as if somebody asked me to prove the sky is blue, where I would simply direct that person to look at it.

If you’re the one who made the proposal, then you’re likely the last person who needs an explanation that the decision was based on consideration of supply & demand. I’m just informing you that, from my point of view, it wasn’t a helpful move for those trying to build in this ecosystem. Making something more competitive than it needs to be is what I would call artificial, not to mention promoting sluggish ecosystem growth. The game theory applied here is flawed because it lacks an (empathetic) understanding of the agents involved in the game.

Whether the idea was to make it artificially competitive by reducing the available slots over a given period of time, whether it was designed around Parity’s upcoming annual retreat which is why there is such a long gap between auctions, or whether it was designed to temporarily lock up (more) DOT longer throughout the process by only having 2 auctions per batch & making that drag on for over a month, the point is that it was a decision that was incredibly out of touch with the actual builders in this ecosystem & did not provide for an experience that is attractive to potential new builders looking to call Polkadot home. It was a decision that, intentionally or not, made Polakdot a harder environment to build during a time when the opposite experience should be the goal here.

The above only strengthens one of my original underlying points of this forum post, being that we should be focused on making this ecosystem more accessible to build in, not harder.

Circling back to the topic at hand, I’ll just quote myself from earlier:

I cannot stress enough that there should be a greater sense of urgency when it comes to fostering a welcoming ecosystem for builders as well as a united ecosystem for users.

A commonly promoted & treasury-funded multichain block explorer can help in achieving this goal on both fronts.

18

Alternative suggestion for your post just to make the counter point:

parachains ought to change their business model or be replaced.

19

You are correct in your assertions about needing more support for ‘grass-roots’ networks, but trying to pick on established ecosystem partners is the wrong approach imo.

There is a path to completely rethinking the Substrate Builders Programme but as a fully on-chain incubator model - and I would suggest this approach is better suited to creating a fully common good ecosystem - that doesn’t mean it couldn’t have a commercial model.

Right now there is maybe a misunderstanding about ‘common good’ in general - ultimately, that means accessible to all - or at least means tested, but it does not mean it is ‘free’. Public services are ultimately funded by a government through taxes - those services are either free for all, or on a continuum up to paid, but subsidised. In this example, the tax payers of Polkadot’s United States are the Parachain States.

Right now the Polkadot treasury (or Kusama) is the Public Treasury you believe should foot the bill and yet you also introduce the flaw in this argument with your points above - crowdloan auction demand is the only thing holding up the value of DOT (or KSM), without some new demand drivers for slots, the model is unsustainable - for everyone… outside of hype, the key question is not about the relay, but about the lack of good parachain business models… aka the States are bankrupt and are asking to be bailed out by the Fed.

This is a useful post for highlighting a tension within a much bigger and more complex problem. Arguing about Subscan’s business model distracts from the bigger issues - which should cause more concern.

3 Likes
20

Try statescan? It’s funded too by the dotsama treasury and has extremely polished UI. Though XCM is still in plan, the current solution is enough for a para-chain’s routine business to explorer history extrinsics, account balances/history actions.

It’s open source, check the code here.

1 Like
21

My apologies, it took me much longer than I anticipated to return to this discussion.

First, I would like to start by acknowledging that @rich is correct & that it’s wrong of me to have started this discussion as what likely comes off as an attack on Subscan - that’s not the right nor best way to go about this. The reality is that Subscan is a terrific product that provides a premium experience, and most importantly, @yakio & the Subscan team have every right to pursue a business model that they believe is best for them as an independent ecosystem project. My opinions on that matter should be separated from the matter at hand, which is the need for a common-good multichain block explorer.

I would counter this to say that Polkadot demonstrates a more significant flaw in its business model since it (at least currently) hardly takes in any revenue from its parachain states which can then be reinvested to improve the overall quality of building in the ecosystem. Instead, it relies on network inflation & network inflation alone to fund such initiatives.

It’s very difficult to say that this is a matter of parachains having a failed business model when a) parachains have hardly taken true form & b) overall ecosystem sentiment is arguably at an all-time low, and b) this is regarding a service that would be needed to be integrated prior to any parachain having the time needed to see their (hopefully) thriving business model take flight. Regardless of whether a state is bankrupt or not, it wouldn’t be attractive for anybody to join a nation that consists of broken & unfinished roads. It’s hard for a business in a state, or a state itself, to thrive if outsiders view the nation as hard to navigate & unattractive.

I agree that we should be mindful of what the treasury should cover or otherwise subsidize, and what parachains should be more/less responsible for, but I also believe that a multichain block explorer is a simple & easy to understand the need for the entire nation that is Polkadot.

I was recently given a monthly quote by another ecosystem block explorer provider, in the range of a couple hundred dollars a month in USD. Even if this rate was doubled, I imagine the annual costs to support all chains would be an extremely low number compared to payouts currently being provided to upkeep other block explorer options.

I guess my closing question would be this:

If we are willing to pay $X for a block explorer service for just Polkadot, but can pay $Y for a block explorer that services Polkadot & all of its parachains, and Y < X, shouldn’t this be something that we as a community & ecosystem strongly pursue?

I believe this could provide a strong ROI for the ecosystem beyond what is immediately quantifiable, and will allow individual users to have a more harmonious experience within Polkadot.