The EVM Subnet: Three Identity Precompiles, an End-to-End Test, and No Network to Run It On

What a subnet is meant to be

A separate execution environment that settles against a main chain. The point is to run a different kind of program than the main chain wants to run, while still inheriting its finality.

Here the different kind of program is a smart contract, and the reason to want one is specific: contracts that can ask about identity.

And that is the genuinely interesting part

Three precompiles, which are functions a contract can call as though they were built into the machine:

is this identifier active is this credential valid, from this issuer does this selective-disclosure proof hold

They read state anchored on the main chain, through inclusion proofs against roots the bridge delivers. So a contract could branch on whether its caller holds a credential, without the contract or its author ever seeing the underlying data.

The logic is written as plain Rust and kept separate from the virtual machine, so it can be tested and fuzzed directly rather than only through contract execution. That is a deliberate and good structural choice.

And the module documents an end-to-end test: a real compiled contract deploying and transferring through the subnet.

And now the measurement

Nothing in the workspace depends on it. The subnet crates are consumed by no binary, and the node that runs this network does not link them.

Five Ethereum-compatibility calls were tried against the public endpoint. All five are refused as unknown methods.

CONTROL: this chain's own methods answer on the same endpoint in the same sweep, so those are readings rather than an unreachable host.

So there is no subnet running, no contract deployed anywhere a reader can reach, and no address a contract could be called at.

Which makes the noun the finding, again

A subnet is a network. This is a crate.

Everything above about precompiles is true about code and nothing about a deployment, and the distance between those two is the whole of this page. A reader evaluating whether contracts on this chain can check identity should know the answer is "the mechanism exists and there is nowhere to run it".

And the build order is right, which is worth saying plainly

It would be easy to file this as vapour and move on. It is not.

Building an execution layer, testing it against a real compiled contract, and keeping the identity logic independently testable is the correct order of work. The alternative, standing up a network first and discovering the precompiles do not work, is worse.

The failure this page guards against is not the sequence. It is describing the sequence's first half in the present tense, which is what the word "subnet" does on its own.

It also inherits everything unresolved beneath it

The proofs these precompiles verify are inclusion proofs against a state root, and no endpoint on this chain serves such a proof.

So the bridge that would deliver roots and proofs to a subnet has, on the read surface, nothing to deliver from. That is one more thing to build, and it is not in the crate this page is about.

What you can check yourself

call eth_chainId against the endpoint

It is refused as an unknown method, as are the other four tried here. Then call solidus_blockNumber and watch it answer, which is what makes the refusal a reading.