Gavin Wood and the problem with being in charge

Gavin Wood has a fairly specific idea of a good working day: ten hours to think about a problem, make a prototype or turn scattered thoughts into an article. The difficulty is persuading a company to leave its chief executive alone for that long. Somewhere, a calendar invitation is already preparing its objection.

In October 2022, Wood explained why he was handing Parity’s CEO job to his co-founder Björn Wagner. He liked sustained technical work. The chief executive’s duties required availability. Both were reasonable demands on a person’s time, and they were competing for the same hours. “I’m a thinker, coder, designer and architect,” he wrote.

His subsequent career has kept revisiting that allocation problem. He returned as CEO in August 2025. By July 2026, he was describing a direct focus on technical delivery, with colleagues running the business around him. The question of where Wood belongs has a habit of ending near the software.

First, find your way through a song

There is an earlier Wood worth meeting before the blockchain vocabulary arrives. Born in Lancaster, he studied at the University of York, completing an engineering master’s degree in 2002 and a computer-science doctorate in 2005. His doctoral subject concerned finding your way through recorded music.

A playback bar tells you how far a song has progressed. It offers much less help locating the passage you actually want. In research with Simon O’Keefe, Wood explored adding visual information derived from the audio. Their paper called the resulting annotation a mood bar. Colour supplied clues where a bare strip of elapsed time had supplied distance.

The researchers tested navigation with people who had little opportunity to learn the interface. That choice gave the work a pleasantly unforgiving standard. A listener should be able to find something without first taking a course in operating the music player. The computer’s cleverness had to become useful at the point of contact.

It would be too tidy to claim that a music interface foretold Ethereum. It does, however, make the résumé less abstract. Wood had spent years dealing with what software lets people perceive and do before he began designing systems for people who might never meet.

An idea acquires a rulebook

In January 2014, Ethereum was becoming a public project. Vitalik Buterin’s announcement named Wood as the lead developer of its C++ implementation and Jeffrey Wilcke as the lead on Go. Different teams were approaching a shared design through different programming languages. Agreement about what the machine should do was therefore a practical necessity.

Wood’s Yellow Paper supplied a formal specification. Ethereum’s proposal for programmable transactions acquired detailed rules: how its machine operates, how execution changes state and how computational work is charged. Those details give independently written software something more exact to agree on than an attractive description of the future.

Formal specifications rarely receive affectionate public attention. Equations do not generally improve a party. Yet this kind of document has a social function: it gives people a common reference when their implementations disagree. A rule written precisely enough can be challenged, tested and translated into working code.

“Less trust, more truth.”

Gavin Wood, on his idea of Web3

The development record also complicates the solitary-founder picture. Wood proposed Solidity, the language for writing smart contracts. His October 2014 update described Christian Reitwiessner prototyping and implementing it. By December, other colleagues were helping with documentation machinery. An idea moved through a team before it became something other developers could use.

These updates contain the texture that achievement lists tend to rinse away: hiring, tooling, an office taking shape, colleagues finding chairs. A system intended to coordinate strangers still needed an organised room in which its first collaborators could work. Even decentralisation has furniture.

In December 2014, Wood was still bringing the Yellow Paper into line with protocol changes so a security audit could proceed. The relationship between document and implementation ran in both directions. A specification had to describe the machine people were actually preparing to release. Precision was a continuing task, requiring revisions as the work developed, rather than a certificate issued once at the beginning.

Who gets to change the rules?

Alongside Ethereum’s machinery, Wood was developing an argument about the internet. His April 2014 essay on Web 3.0 described a system in which users would need to entrust less information and authority to organisations. The concern was the power that accumulates when a service becomes the unavoidable middle of an interaction.

Encryption, publication and agreements were parts of that proposed web. The point was to arrange interactions so that participants could rely more on inspectable mechanisms. Wood’s later shorthand about trust and truth made the ambition memorable, although the engineering required considerably more than five words.

Read as an argument about power, his work becomes easier to follow. A platform operator can set conditions. An institution can interpret a promise. Software can encode conditions that participants examine in advance. Whether any particular implementation delivers the promised freedom remains a question for its actual design and operation.

There is a demanding bargain inside that ambition. Making rules explicit exposes them to scrutiny, but it also raises the stakes of getting them right. A protocol has to survive contact with people pursuing their own interests. Writing an elegant account of cooperation is an opening move; building dependable cooperation is the longer game.

A company for the next set of questions

Wood’s January 2016 farewell to the Ethereum Foundation was warmer than a corporate departure notice. He remembered collaborators, signalled a new venture and joked about letting his C++ get rusty. The joke had a technical destination: the company that became Parity would build blockchain software in Rust.

EthCore had been founded in late 2015 by Wood, Aeron Buchanan, TJ Saw, Ken Kappler and Jutta Steiner. Wagner joined as a co-founder the following year. The early group used fluid responsibilities rather than treating titles as the main organising principle. That preference would remain visible when Wood later explained his own changing duties.

Polkadot brought a different architectural question into view. Instead of putting every application into one shared execution environment, could several specialised chains work alongside one another while sharing security? The design made room for variety. It also made communication between those separate environments an essential engineering concern.

Parity’s Substrate framework, introduced in 2018, supplied tools for constructing custom blockchains. Kusama launched in 2019 as a canary network, allowing the ecosystem to try ideas in a live setting. Polkadot’s mainnet followed in 2020. The experiments had become software, networks and responsibilities extending beyond their original authors.

There is a useful distinction between creating an architecture and creating the conditions for other people to build on it. Frameworks, documentation and working examples matter to the second task. Wood’s writing career includes co-authoring Mastering Ethereum, a reminder that explaining the machinery can itself become part of the infrastructure.

Yellow, white, gray

The Gray Paper introduces JAM, the Join-Accumulate Machine. Its proposed architecture draws on both Ethereum and Polkadot: the usefulness of a shared environment, and the capacity of a network to carry out substantial computation in parallel. The challenge is letting more work happen without leaving every piece of it isolated.

Imagine several workshops producing components that must eventually fit together. Giving each workshop more benches increases activity. It does not automatically make the components compatible. JAM separates kinds of work and provides mechanisms for their results to enter a shared environment. The analogy explains the coordination problem; the specification supplies the actual rules.

As of October 12, 2026, Parity described the intended Polkadot transition as active engineering work. The public Parachain Service implementation remained a proof of concept. Integration, benchmarking, testing and security work still stood between architectural demonstration and production readiness. A paper can define the destination with considerably more confidence than a calendar can supply the arrival date.

For developers considering that architecture, the distinction matters. A proposal describes what should be possible; a service they can depend on has to demonstrate consistent behaviour under real demands. Wood’s public JAM lectures open another route into the design, working through its vocabulary and motivations. Teaching it creates an additional obligation: an architecture must be explainable to the people expected to implement it, question it and eventually build services on it.

Back within reach of the code

Wood’s August 2025 return to the CEO role followed nearly three years of Wagner’s leadership. He framed the return as a way to connect architectural direction with execution. By July 2026, his stated priority had become leading technical delivery directly, turning proofs of concept into usable open-source software.

That July note described an able team running the business around him. It also acknowledged the departure of engineering vice-president Pierre Aubert. Responsibility was being arranged around the work ahead. For someone who had once explained his preference for a long stretch with a problem, the arrangement had an intelligible appeal.

Wood’s public record is full of attempts to make complicated things explicit: a coloured cue inside a song, the operation of a virtual machine, the relationships between chains. The projects differ. In each case, people have to find their way through something someone has designed.

His next chapter will be assessed in running software and what others can do with it. The title is useful for the business card. Somewhere behind it waits a difficult problem, and, with luck, a reasonably clear calendar.