CitizENS is a new series spotlighting the people building, improving, and shaping ENS, and the work happening behind the scenes to move the protocol forward.
The first time Marcus imported a DNS domain into ENS cost him around $200.
It was 2023, gas was expensive, and the experience left him with a fairly reasonable conclusion: "Okay, no one will do this."
The expensive part was proving, cryptographically and onchain, that the person claiming a DNS domain actually controlled it.
Three years later, that verification looks very different. Before Fusaka, ENS's DNSSEC Oracle verified P-256 signatures through a Solidity elliptic-curve implementation, which made the operation computationally expensive. It can now use Ethereum's native P-256 precompile instead.
The result: the gas required to verify a signature during an onchain import has fallen from 1,340,706 gas to 10,493, a 99.2% reduction. Across eligible imports between March 9 and July 27, a historical replay estimated that the change saved 1.12 billion gas.
Behind that improvement is a question that keeps showing up in Marcus's work:
"What makes a name actually trustworthy, not just resolvable?"
ENS lets the controller of a DNS domain bring that name onchain. But first, ENS needs a way to verify that the person making the claim actually controls the domain.
That's where DNSSEC, short for Domain Name System Security Extensions, comes in. DNSSEC adds cryptographic signatures to DNS, creating a chain of trust that ENS can verify. To import a name, the controller enables DNSSEC, publishes a record proving control, and submits that proof through the ENS DNS Registrar. The DNSSEC Oracle verifies it before the name can be claimed in ENS.
That cryptographic proof is where Algorithm 13 and P-256 enter the picture.
DNSSEC can use different cryptographic algorithms to verify that DNS data is authentic. Algorithm 13 is one of them, and it uses P-256, a widely used cryptographic curve. Until recently, Ethereum didn't support P-256 verification natively through its P-256 precompile.
That was the gap Marcus became interested in closing.
Marcus didn't arrive at ENS as a protocol engineer. Before crypto, he worked in the music industry. He first encountered ENS as a user, eventually started contributing to the DAO, and taught himself the technical side as he went. He didn't take his first Git course until 2024 and says that, before then, he barely knew what a terminal was.
The story behind cheaper DNS imports began with an RFP from ENS founder Nick Johnson around native P-256 support on Ethereum. Marcus dug in and started advocating for the change. Along with then-Public Goods steward Colton, he helped identify developers already working on it, while the ENS Public Goods Working Group helped fund that work.
Then came the waiting. Native P-256 support eventually landed on Ethereum. Once it did, Marcus contributed a change to the ENS contracts that routed Algorithm 13 verification through Ethereum's native P-256 precompile instead of the previous implementation.
His high-level explanation is almost comically simple: point the verification at the native precompile instead.
The effect was considerably less modest.
The study of the updated verification path found that verifying an Algorithm 13 signature fell from 1,340,706 gas to 10,493. Put another way, the same verification step now uses less than 1% of the gas it used before.
That doesn't mean every DNS import suddenly became 99.2% cheaper. Algorithm 13 verification is one component of the import, and the dollar cost of a transaction also depends on Ethereum gas prices. What changed was the amount of computation required for one of the most expensive parts of the process.
Marcus's own $200 import makes the difference tangible. Today, he estimates a DNS import can cost only a few dollars under current Ethereum Mainnet gas conditions, although that comes from both the P-256 improvement and much lower Ethereum gas prices.
There is also a longer-term benefit. Gas is relatively inexpensive today, but reducing the computation required makes eligible DNS imports less sensitive to future spikes. Marcus calls that "future-proofing."
He could have stopped once the contract change shipped. Instead, after a conversation with Makoto at an ENS event in Lisbon, he built a Dune report to find out what the change had actually done at protocol scale.
The resulting study replayed recorded ENS DNS imports and estimated 1.12 billion gas saved across eligible imports between March 9 and July 27.
"I think it's really important to demonstrate proof of work instead of just saying, 'Here's a thing that I built. Good luck trying to figure out what this means.'"
Cheaper verification matters beyond one less expensive transaction.
Registries, domain communities, and subname platforms can use existing DNS namespaces as a foundation for ENS names underneath them. A controller of example.com, for instance, could bring that name into ENS and issue names such as blog.example.com.
That matters as new gTLD applicants make decisions about DNSSEC and registry infrastructure, while ICANN's Technical Study Group examines how DNS domains could coexist with alternative naming systems under the same controller.
Marcus's analysis found Algorithm 13 in use across 11.5% of the gTLDs represented in its registry-level dataset. That isn't a forecast of ENS adoption, but it shows that the cheaper verification path is already relevant to part of the DNS landscape.
It also leads to the problem Marcus is thinking about now.
Connecting an entire top-level domain to ENS involves more than verifying a signature. There are questions around control, transfers, expiry, and governance.
"Importing TLD names to ENS is the biggest challenge because it's not just technical, it's social," Marcus said.
He has been experimenting with a TLD Oracle that could let operators prove control through DNS and reduce the amount of manual governance required to anchor namespaces into ENS. The idea is still exploratory, and Marcus is clear that code alone won't solve the coordination problem.
"You can't just write code for it," he said. "You need to meet people, coordinate, have these offchain agreements, and then you can build the code around it."
That fits neatly with the question he says ties his projects together: what makes a name trustworthy, not just resolvable?
Marcus's motivation is less about any one feature than becoming the kind of builder who can spot an "invisible problem" and do something about it.
"What keeps me motivated is just my own desire to become a better builder and be of more value to the protocol overall," he said.
Most people importing a DNS domain into ENS will never think about which elliptic curve is being verified, which contract is doing it, or how much gas the operation used to consume. They'll just notice that it works and costs a lot less than it used to.
Marcus seems perfectly comfortable with that.
His way of working is fairly simple: find a problem, understand it well enough to do something about it, ship the solution, and move on.
"I identify a path, I tackle it, I close it, and then, like, next," he told us.
Right now, "next" means thinking about how entire DNS namespaces could connect to ENS with the same kind of trust guarantees, without making every step a governance exercise.
A few years ago, Marcus was looking at ENS from the outside and teaching himself how the pieces worked. Now he's looking for the pieces that could work better.
And usually, once he finds one, he starts building.