The Architecture of Digital Trust A few months ago, I was talking to a friend who had been contributing to a DAO for almost a year. He had voted on proposals, participated in community discussions, reviewed work from other contributors, and even built a small tool that people in the community were actively using. If you looked at his wallet, there was evidence of almost everything he had done. Yet when he introduced himself to someone outside that community, none of that history really followed him. He had to start from the beginning. He had to send links to proposals he had voted on, find old conversations, point people towards repositories, and explain what he had contributed, where he had contributed it, and why any of it should matter. The information existed, but it was scattered across different platforms and difficult to interpret as a coherent history. That conversation stayed with me because it exposed a rather strange contradiction in the way we have built Web3. We have spent years building systems that allow people to own their identities, move assets without permission, participate in governance and interact with applications without depending entirely on centralized accounts. We have become increasingly comfortable with the idea that an individual can carry their identity and assets across different digital environments. Reputation, however, has not followed the same path. Today, much of our understanding of a person’s credibility still comes from social media followers, screenshots, profile descriptions, personal introductions, recommendations and claims that are difficult to verify. A person’s contribution to one community may be almost invisible to another. A developer can spend months building infrastructure without anyone outside a small group knowing what they have done. A delegate can participate consistently in governance while having little way to communicate that history beyond individual proposals and forum posts. The information is there. What is missing is a meaningful way to bring it together. This is where ENS can become more than a naming system. An ENS identity can serve as the foundation for a richer representation of the person behind the address. Instead of an ENS name simply pointing towards an address or storing a collection of records, it can become a doorway into a verifiable history of participation. The Reputation Passport proposes an open reputation layer built around ENS identities. It would collect relevant, verifiable signals from a person’s onchain activity and connected ecosystem contributions and present them as an understandable profile. The purpose is not to create another social profile, nor is it to reduce a person to an arbitrary reputation score. It is to make meaningful contribution easier to discover and easier to verify. Consider what this could look like in practice. A developer with an ENS name could have a profile showing the open source projects they have contributed to, alongside relevant governance participation and verified ecosystem work. A delegate could demonstrate their voting history, participation rate and areas of governance they have consistently engaged with. A researcher could connect published work and governance contributions to the same identity. A community contributor could establish a visible record of sustained participation even if they have never accumulated a large following on social media. None of these things should need to be proven through a carefully assembled collection of screenshots every time that person enters a new community. The blockchain already provides a considerable amount of evidence. The challenge is that raw activity does not automatically translate into reputation. A wallet with hundreds of transactions tells us very little on its own. It does not immediately tell us whether the owner is a developer, researcher, governance participant, trader, contributor or simply someone who has interacted with a large number of contracts. Transaction history is evidence of activity, but activity needs context before it becomes meaningful. That distinction is central to this proposal. The Reputation Passport should therefore avoid the temptation to create a single number that claims to represent the worth of an individual. Giving someone a score of 87 and another person a score of 54 may look convenient, but it raises questions that are difficult to answer honestly. Is voting in ten governance proposals worth the same as contributing code to an open source project? Is receiving a grant more valuable than maintaining documentation? Should financial activity increase someone’s reputation? Who determines the weight assigned to each action? A universal score would inevitably embed subjective assumptions into something that should remain transparent. Instead, the Passport should preserve the context behind reputation. A profile could show governance participation, development contributions, ecosystem involvement, verified projects and other relevant signals independently. Someone looking at the profile would be able to understand where a person’s reputation comes from rather than being asked to trust an unexplained algorithm. That distinction becomes particularly important when considering governance. Governance depends heavily on trust. Delegates ask communities to give them voting power, often on the assumption that they will participate responsibly and make informed decisions. Yet choosing a delegate can still involve a surprising amount of guesswork. A social media following does not demonstrate governance competence. A polished profile does not demonstrate participation. Even a strong public reputation does not necessarily tell someone how a person has actually behaved when given the opportunity to influence decisions. A verifiable governance history can provide a much stronger foundation. An ENS identity could communicate how consistently someone has participated, which proposals they have engaged with and other relevant aspects of their public governance record. This would not determine who deserves voting power. It would simply make the information required to make that decision easier to access. The same principle applies to builders. There are people throughout Web3 whose contributions are much larger than their public visibility suggests. They write code, maintain repositories, review proposals, design interfaces, produce documentation, support users and maintain infrastructure. Their work may be deeply valuable while their social presence remains relatively small. Reputation should not be a popularity contest. If contribution can be verified, it should have a place within someone’s digital identity. This is also why the project should not become another isolated website. The value of a reputation layer increases when other applications can make use of it. A governance platform could retrieve a delegate’s verified participation history. A grant platform could display a contributor’s ecosystem record. A wallet could provide users with a richer understanding of an address. An ecosystem directory could surface builders based on demonstrated contributions rather than follower counts. For that to happen, the Reputation Passport would need more than a user interface. It would require an underlying reputation engine capable of collecting relevant data, interpreting it consistently and presenting the evidence behind each signal. An open API and SDK would then allow other developers to build on that infrastructure rather than recreating the same systems independently. The ambition is therefore larger than a profile page. It is an attempt to establish a common layer through which reputation can become portable. There is an important privacy consideration here as well. A reputation system should not become an excuse to expose every detail of someone’s activity or create a permanent surveillance record. The project should work primarily with information that is already public and relevant, while making a clear distinction between information that is independently verifiable onchain and information that a user has voluntarily connected or verified. The objective is to give people greater control over how their contributions are represented, not to remove their control over their identity. The first version can remain deliberately focused. ENS identity and records would provide the foundation, with governance participation, open source contributions and selected ecosystem activity forming the initial reputation categories. Each significant signal should have a clear source so that users are not simply asked to trust the Passport itself. Where possible, the underlying evidence should be inspectable. From there, the system can develop according to how people actually use it. If delegates find the governance history useful, that part of the system can become deeper. If developers begin using the API to surface contributor histories, additional developer signals can be introduced. If ecosystem projects find value in verified contribution records, those integrations can expand. The goal is to build an infrastructure layer that grows from demonstrated utility rather than trying to predict every possible use case from the beginning. The long term opportunity is a change in how digital identity carries history. Today, entering a new community often means starting from zero. Your previous contributions may exist, but they remain locked inside the places where they happened. You may have spent two years building, voting, researching or supporting an ecosystem, yet still need to introduce yourself as though none of that history exists. A more mature digital identity should be able to carry evidence of participation with it. Not a popularity score. Not a leaderboard. Not a judgment about who is trustworthy. Evidence. That is the distinction I want the Reputation Passport to preserve. ENS has already established a powerful foundation for human readable identity. The next question is what that identity can represent beyond a name and an address. If an identity can point to a wallet, and a wallet contains a history, then there should be a way to make that history understandable without forcing every person to reconstruct it manually. The Architecture of Digital Trust is ultimately about that missing layer. Web3 has become very good at proving that an action happened. The next step is making the significance of those actions easier to understand. People are building. People are voting. People are contributing. People are maintaining infrastructure. People are showing up. Their history is already there. The Reputation Passport is an attempt to give that history a place to speak.