I do want to note to people that supply chain attack is a real risk. We’re having a lot of reputable and established teams exiting Polkadot at this moment, and we’re also seeing a few new faces joining, many times anonymous. The anti-scam team has also stopped.
I don’t want to discredit anyone’s work, but if you choose to be anonymous and enjoy the benefits of not revealing your real name, you probably should also accept that others taking a slightly higher bar for your project.
Especially against high-value targets, supply chain attacks happen frequently. If you consider yourself one, you should be really reluctant to trust new, anonymous teams. The scenario is really easy for an attacker – they just need, for example, a Polkadot SDK maintainer to clone a repo, and they can infect the entire ecosystem.
A lot of supply chain attack holes are present in our own ecosystem in many many places that I also don’t want to mention to give attackers ideas.
It unfortunately always starts with some new anonymous faces.
The purpose of this forum is to constructively discuss the ideas proposed, so the community should focus on the idea in question, it should be analyzed and evaluated without diverting readers’ attention to controversy, hypotheses, or accusations… it shouldn’t be a witch hunt.
I think it’s right that those who have the skills and can verify the code can do so. If the proposal is interesting and the code is good, I think the fact that the account is anonymous is irrelevant. In an open-source world, code is law.
Ser, I am not a new face. I’ve been here since before the parachains launch. You can check my X profile. I also made another proposal on this forum some time ago about burning transaction fees.
I’ve read this entire thread. The exchange between @Vincent and @ultracoconut on interface design, type mapping, and which pallets to prioritize — that’s exactly what forum discussions should look like. Technical, iterative, productive. But that exchange got buried under unnecessary friction.
A few thoughts.
On the proposal. Standardized EVM-compatible interfaces for Substrate pallets is a real idea worth exploring. @Vincent’s questions about scope — which APIs first, how to handle Substrate types that Solidity can’t express natively — are the right ones. That’s the conversation this thread should be having.
On anonymity. This is a cypherpunk ecosystem. Satoshi was anonymous. The entire premise of permissionless systems is that contributions are evaluated on substance, not credentials. @ultracoconut has every right to remain anonymous, and the community should respect that. That said — the OP’s framing invited confusion:
That reads like an announcement from someone with the authority to make that commitment, not a community proposal seeking feedback. When the framing implies institutional backing, people will ask who’s behind it. A clearer framing — “I’m proposing the community signal support for this, for Parity and the Fellowship to implement” — would have avoided most of the friction.
On supply chain risk.@sorpaas raises a legitimate concern. Anonymous code contributions to critical infrastructure do carry risk. But the answer is code review, auditing, and reproducible builds — not deanonymization. And this proposal is an interface specification at this stage, not a runtime patch. The risk profile is different, and the response should be proportionate.
On the escalation. The personal attacks on both sides undermine the people making them more than the people they’re aimed at. The developers watching this thread — the ones evaluating whether to build on Polkadot — draw conclusions about the ecosystem’s maturity from exchanges like this. We should care about what they see.
@ultracoconut, the RFC process that @josep pointed to is genuinely good advice regardless of how it was delivered. A structured proposal with defined interfaces would get the kind of technical review this idea deserves. @josep, if the proposal has holes, name them — that’s the contribution this thread actually needs.
I’m really unhappy when someone doesn’t actually read the “entire thread” and then claim they’ve read the “entire thread”.
I dare you to find anything, even a hint, that I could have suggested the answer is “deanonymization”. Otherwise, I ask you to retract your following statement:
Fair point, @sorpaas. You didn’t suggest deanonymization — you suggested a higher bar for anonymous contributors, which is a different thing. I drew a contrast that wasn’t there. That’s on me.
For what it’s worth, I agree with your actual position. A higher bar for anonymous contributors is reasonable, and code review, auditing, and reproducible builds are how that bar gets applied in practice. We’re saying the same thing.
Thanks, this clarifies a lot.
My goal is not just raw dispatch via RUNTIME_PALLETS_ADDR, but exposing selected pallets as ABI-friendly virtual contracts, so they can be consumed through standard EVM tooling (ethers.js, viem, etc.) without manual SCALE encoding.
Essentially a higher-level adapter on top of the existing runtime dispatch capability.
through standard EVM tooling (ethers.js, viem, etc.)
This is not a good idea. Its moving a lot of data-marshalling complexity onchain, where it doesn’t belong. Users in the off-chain context can just use PAPI to directly call the substrate APIs and be done with it. Or you could implement an EVM-esque wrapper around PAPI if you wanted.
I believe there is value in having a select few precompiles that that can be called by on-chain contract code. To make bridging, XCM, and a few other processes easier for Solidity devs writing contracts. That’s why I initially supported aspects of your proposal.
Overall, I sense that you’re struggling to define the problem with sufficient technical depth and rigor, which isn’t helping your case.
Thank you for the feedback.
I think there is a very important aspect that may not be fully aligned in our perspectives: composability with the virtual machines.
The main value of this system is not to simplify off-chain calls — PAPI already serves that purpose well. The value lies in enabling EVM and PVM contracts to call these virtual contracts directly during their execution.
This unlocks something that an off-chain API cannot provide:
Atomicity between contract logic and pallet calls.
True composability between VM contracts and runtime logic.
Fully on-chain orchestration without relying on external infrastructure.
The goal is not to move unnecessary complexity on-chain, but to expose a minimal and controlled interface that allows VMs to interact with the runtime in a deterministic way.
Overall, I received a very positive response from the community. They really liked the idea of designing a higher-level layer for programmability, with Substrate serving more like a kernel underneath.
In the end, neither you nor I decide — the community does.
You might want to check the Moonbeam and Hydration repos first.
Moonbeam Network already covers this, and Hydration has it solved as well. In the case of PVM, I guess that you’re a bit confused because there’s no EVM running anywhere.
Most of what you’re suggesting isn’t new territory. It’s already implemented in different ways. It does not really make sense to try to reinvent this without first understanding how those systems actually work, what’s PVM and why they were designed that way.
Generally i agree that we will need precompiles for practically every major pallet on assethub. A few i can already see being useful can be staking (which can power liquid staking protocols), governance, nomination etc.
Maybe a great solution would simply be a single precompile that can recieve scale encoded runtime calls and dispatches them with the calling contract address as signer. So we avoid having multiple precompile interfaces
I suggested the need for something along these lines a while ago. But IMO this should be treated as an escape hatch, not as “the solution”.
The reason is simple: we still need precompiles with stable APIs for mission-critical functionality. If the main integration path is “dispatch arbitrary SCALE-encoded runtime calls”, you can’t reliably build/combine higher-level abstractions on top, because runtime upgrades can subtly change pallet call layouts/semantics and break contracts. Therefore, that implies either ossifying some less than ideal pallets that can’t upgrade, or not having proper composability.
@ultracoconut I’m struggling to take the proposal seriously enough to invest time reviewing it in depth, mainly because it doesn’t seem to benchmark itself against the tradeoffs of the solutions that already exist (as @sodazone pointed out). Without that comparison, it’s hard to evaluate what we gain and what we lose.
Also, some parts read internally inconsistent. For example:
You say the precompile verifies an H160 signature and then links that H160 to an AccountId32. Even granting that approach (similar to what pallet-revive does, with its own tradeoffs, which is far from a silver-bullet solution),
then you say the runtime constructs a new SIGNED extrinsic, signed again with a “runtime-controlled proxy key”.
If the signature has already been verified, why is there a second signing step at all? Why not treat this as an already-checked payload (e.g., a CheckedExtrinsic) and dispatch directly?
Related: what exactly does “runtime-controlled proxy key” mean here? Where is that key material stored, what are the security assumptions, and how does this avoid becoming a privileged signer/origin?
Stepping back, it’s hard for me to take this seriously right now because the whole thing feels too shallow and, in places, frankly nonsensical.
I’m not reinventing the wheel; it’s better that everything’s already been done. I just want a better UX and DX for Asset Hub, and for that, in my opinion, the H.160 and Solidity standards are necessary. Substrate should be used as a lower layer for system developers, validators, etc.
Of course it can be improved;
The important thing is that the VMs and palettes are composable and that dApp developers don’t have to deal with Substrate at all.
This is a very nice and noble goal, for sure. However, as I already pointed out several times, your proposal doesn’t actually accomplish this goal. You are oversimplifying things.
