Fluent: A Unified Operating System for Reputation

1. In Search of Trust Infrastructure

Source: todorbozhinov.com

In the eleventh century, Maghribi traders in the Mediterranean had to entrust their goods to agents in Sicily, thousands of kilometers away. With no cross-border legal system to enforce contracts and no central authority to guarantee fulfillment, how did they manage to trust one another?

The solution, as economists have shown, was a multilateral reputation coalition. If an agent cheated even a single merchant, the news spread across the entire Mediterranean through a network of letters, and the branded agent was shut out of every trading opportunity within the coalition.

Yet the reputation produced by this system was inherently one-dimensional. What the letter network tracked was a single binary signal: "Is this agent honest or not?" It did not capture the richer layers of information that mattered in practice, such as who had expertise in trading particular goods, how disputes had been resolved, or whether an agent had a track record of pioneering new trade routes. On top of that, the coalition could only function in a network small enough for every member to recognize every other, so it hit a ceiling as trade expanded and participants grew more diverse.

The Champagne fairs of 12th and 13th-century France represented a step forward. The "Law Merchant" system introduced there maintained systematic records of traders' behavior: whom they had traded with, what disputes had arisen, and how those disputes had been settled. Merchants could look up a counterparty's history before entering a deal. Compared with the binary reputation of the Maghribi coalition, this was a far more layered approach to managing trust information.

Even so, the Law Merchant's ledger had a fundamental limitation: the reputation it recorded was bound to the specific marketplace of Champagne. Decades of trade history and demonstrated reliability that a merchant had accumulated there effectively reset to zero the moment that merchant moved to a different market. Reputation was recorded, but it was not portable.

These problems were ultimately overcome in the modern era through the emergence of notarial systems, commercial registries, and, most decisively, credit bureaus. FICO synthesized the multi-layered information of an individual's financial history into a single score, made that score portable across institutions, and was designed to operate on top of identity verification mechanisms such as Social Security numbers.

Reputation could overcome its historical constraints only when it evolved beyond the scope of particular relationships or particular marketplaces to the level of infrastructure.

2. Reputation Systems in the Crypto Ecosystem

So what form do reputation systems take in the crypto ecosystem?

The crypto ecosystem lacks a universally enforceable identity framework. Even if one were to be introduced, behind a single on-chain address sit individuals under the legal jurisdictions of countless different nations, and there is often no way to determine whether the address belongs to a human or a bot. In an environment where the institutional foundations of traditional trust cannot simply be imported, the same problems must be solved in fundamentally different ways. This is the core challenge facing crypto reputation infrastructure.

2.1 The Current Landscape of Reputation Protocols

It is not as though the crypto ecosystem has never attempted to measure reputation. Over the past several years, a variety of protocols have sought to quantify user trustworthiness, and these have been used to support various efforts at community identification, from weighting airdrop allocations and token presale access. Categorized by the type of data each project collects, the landscape looks roughly as follows.

2.1.1 Social Activity-Based

• Kaito: Uses an AI engine to analyze the originality and influence of posts on X, producing a "Yaps" score as a measure of social influence. (Currently switching to Kaito Studio, a selective creator marketing platform, in line with X's policy update)

• Moni: Employs AI to analyze the duration and content of a user's activity on X, assigning a score accordingly.

• Galxe: Accumulates records of quest completions across projects to generate its own score (Galxe Passport Score).

• Talent Protocol: Derives a Builder Score from builder-related activity such as GitHub commits and LinkedIn experience.

2.1.2 Peer-to-Peer Vouching-Based

• Ethos: Produces a credit-like score through user-to-user reviews, vouches, and slashing. An invitation-based system provides Sybil resistance, while a binding design in which a voucher's reputation is linked to the person they vouch for creates a chain of accountability.

2.1.3 On-Chain Activity-Based

• DegenScore: Measures proficiency based solely on Ethereum DeFi and NFT activity history, issuing a non-transferable soulbound token (Beacon) to users scoring above 700.

• Nomis: Analyzes over 30 parameters (balance, transaction volume, wallet age, etc.) through a mathematical model to produce a reputation score from 0 to 100, minted as a soulbound token.

• FairScale: Combines on-chain and off-chain indicators through an AI-based approach to generate user scores.

• DeBank: Calculates a comprehensive credit score across five dimensions: identity verification, proof of assets, platform behavior, user relationships, and misconduct. With a user base of 3.2 million, it has carved out a distinctive position by combining portfolio tracking with reputation.

2.1.4 Proof of Identity-Based

• Human Passport (formerly Gitcoin Passport): Designed as a means of distinguishing bots from humans, it collects a variety of information from users, including Google accounts, GitHub accounts, and government-issued IDs, to compute a score.

As this overview shows, the crypto ecosystem currently has at least ten protocols attempting to quantify and use reputation scores. Yet each of these collects different data in different contexts, and they share no unified standard. To put it with slight exaggeration, the state of reputation systems in today's crypto ecosystem is roughly comparable to that of the medieval traders described in the introduction.

2.2 The Real Costs of Fragmentation

The reputation protocols surveyed in Section 2.1 each capture meaningful signals. But when a project faces the practical decision of "who should receive our token allocation," the fragmentation of these protocols generates costs that go well beyond mere inconvenience, creating structural inefficiencies.

First, inconsistent criteria force wasteful re-measurement of reputation. Reputation protocols typically serve as reference metrics when determining airdrop allocations or token presale quotas. The problem is that each protocol defines "good user" differently, and the projects distributing tokens have their own criteria as well. For one project, a "good user" might be a developer capable of making technical contributions; for another, a long-term holder who will stay in the community; for yet another, an influencer who can expand awareness beyond the ecosystem. Because none of the existing reputation protocols satisfies all of these contexts simultaneously, projects ultimately choose to design their own criteria from scratch.

The result is that nearly every project builds its own pipeline for determining "who is real" from the ground up. Monad, for instance, conducted a lengthy review of all accounts to identify CT players with genuine social influence. MegaETH designed its own scoring criteria for on-chain activity history. The resources invested in these processes are consumed as one-time costs that cannot be reused across projects.

Second, data that is never submitted on-chain is fundamentally unverifiable. A significant portion of the data referenced by current reputation protocols exists off-chain. Kaito's social activity on X, Talent Protocol's GitHub commits, and similar data points fall into this category. While this data is collected through each platform's API, no on-chain mechanism exists to independently verify its authenticity. There is simply no way to determine on-chain whether a user's X influence has been inflated by a bot network, or whether GitHub commits represent substantive contributions or superficial activity.

Third, reputation does not cross ecosystem boundaries. Years of DeFi activity that a user has accumulated in the Ethereum ecosystem are typically not recognized in the Solana ecosystem. Even someone with a strong reputation on one platform must start from a blank slate when applying for a token sale on another.

These three problems are not independent of one another. Because reputation is not portable across ecosystems, each project must create its own criteria. Because independently created criteria cannot construct sufficient context from verifiable on-chain data alone, they end up relying on unverifiable off-chain data, which in turn makes the system vulnerable to manipulation. Fragmentation is not a minor inconvenience; it is a vicious cycle that structurally inflates trust costs across the entire crypto ecosystem.

2.3 Possible Approaches to Resolving Fragmentation

To break this vicious cycle, three things are needed: a composite reputation framework flexible enough to accommodate diverse contexts, a proof mechanism that anchors off-chain data in a verifiable form, and cross-chain compatibility that unifies data from different execution environments into a single layer. Can existing approaches satisfy all three requirements at once?

The most intuitive solution is to read data from multiple chains on an off-chain server, aggregate it, and record only the result on-chain. However, this model has two fundamental limitations.

The first is a lack of composability. For an on-chain protocol to reference a reputation score computed off-chain, it must fetch that score through an oracle. At that point, a lending protocol determining its collateral ratio becomes dependent on the honesty of the oracle, and any latency between oracle updates creates an exploitable gap. By contrast, if reputation logic resides in the same execution environment, the reputation contract can be called directly within the same transaction, and the trust guarantee is provided by the execution environment itself.

The second is a lack of censorship resistance. An off-chain aggregator can arbitrarily manipulate or exclude a particular user's reputation, and outsiders have no way to audit the process. If reputation is to function as an economic variable, one that determines lending rates and assigns governance weights, the computation behind it must itself be verifiable.

The next option to consider is cross-chain messaging protocols such as LayerZero. These protocols, however, are designed for data transmission, not for unified execution of data. A cross-chain messaging protocol can send a reputation score from Chain A to Chain B, but combining a score produced by an EVM contract on Chain A with a score produced by an SVM contract on Chain B within the same execution environment to compute a single composite reputation is beyond the design scope of these protocols.

Finally, there are attestation protocols. The Ethereum Attestation Service (EAS) provides a general-purpose primitive that allows "anyone to attest to anything on-chain," and experiments are already underway using it to record reputation data on-chain and make it interoperable across platforms. However, current attestation protocols, EAS included, operate most effectively within a single VM ecosystem. Activity from Solana's SVM can be recorded in Ethereum's EAS, but the integrity of the underlying data relies on off-chain oracles in the process.

In conclusion, to build an environment at the infrastructure level that preserves and leverages the full economic value of reputation in the crypto ecosystem, a layer is needed that can run logic from different VMs within a single execution context. Fluent's blended execution environment possesses the technical foundation that aligns with this requirement, and the next section examines it in detail.

3. Fluent: Toward an Operating System for Reputation

3.1 The Blended Execution Environment as a Technical Foundation

Source: Fluent

One of Fluent's most distinctive features is its "blended execution" environment, which can run EVM, SVM, and Wasm-based applications within a single unified execution environment.

Fluent is built on rWasm, a Wasm variant optimized for zero-knowledge proofs. It can simulate EVM and SVM operations and compile them into a single unified state transition function. The fundamental difference from existing multi-chain solutions is that smart contracts from different VMs can share the same state and interact atomically without bridges.

The point at which this architecture intersects with reputation infrastructure is clear. To weave data measured by different reputation protocols into a single composite reputation, a layer is needed that can read, combine, and prove data from different execution environments within the same context. The blended execution environment provides exactly that foundation. For example, it enables a scenario in which an EVM-based reputation contract written in Solidity calls a Wasm analysis engine implemented in Rust, and the result is then referenced by an SVM application.

More concretely, the value that such a blended execution environment can deliver is best captured by three capabilities.

• Realizing composite reputation: A user's social media activity, peer vouches, on-chain transaction history, and proof of humanity can be combined within Fluent's single execution environment. Each data source is verified independently, but ultimately rendered into one unified reputation profile.

• Selective disclosure via zero-knowledge proofs: The ZK-optimized design of rWasm makes it possible to prove whether a specific fact about a user's history is true without revealing the underlying transaction details. Users can selectively prove only the parts of their reputation that are needed, while keeping the rest private.

• Cross-ecosystem portability: The fact that Fluent supports EVM, SVM, and Wasm means that reputation data built on top of it can be recognized and utilized within the same environment, regardless of whether it originated in the Ethereum or Solana ecosystem.

3.2 Fluent Prints and Connect

3.2.1 Prints

"Prints," a product released by Fluent, generates a unique social footprint by linking a user's X account, on-chain wallets, and other sources.

On its own, Prints may not look dramatically different from existing profile aggregation services. What matters, however, is that it operates on top of the blended execution environment rather than as a standalone application, and this is what creates a path between its current functionality and its future potential. If Prints is designed not as a single score but as a "container of contextual signals," then reputation built on top of it can function not as a score, but as a bundle of signals shaped by context, time, and repeated behavior.

3.2.2 Fluent Connect

If Prints is the reputation primitive on the user side, Fluent Connect is the interface for builders. The conventional user acquisition strategy in crypto has relied on quantitative metrics such as Discord member counts, follower numbers, and transaction volumes, all of which create fertile ground for Sybils and bots. Fluent Connect is designed to let builders identify the users who are the best fit for their product, using reputation profiles as the basis for that identification.

Vena Finance (Vena Finance), built on top of Fluent Connect, provides an early experiment along these lines. Whereas conventional DeFi applies a uniform collateral ratio to every user, Vena introduces the concept of "reputation-weighted rates," designing a model in which the price of capital varies according to a user's Prints reputation. While still at the proof-of-concept stage, the project is significant in that it concretely demonstrates the conditions required for reputation to function as an economic variable rather than a mere profile decoration.

3.3 The Possibility of Reputation Infrastructure as Envisioned by Fluent

Source: @blendino

The roadmap that Fluent has published illustrates how reputation infrastructure might evolve.

In the current phase, Fluent Connect provides the foundation for users to build reputation and for builders to discover genuine users. This is the stage that solves the cold start problem for the overall system, the period in which reputation data is initially accumulated and validated.

In the next phase, the ecosystem begins to expand in earnest. Reputation-based preferential-rate lending, credit scoring and buy-now-pay-later, P2P marketplaces, and social apps integrate with Prints and Fluent Connect, forming a structure that "rewards trusted activity." Builders gain access to developer tools including login templates, app and user analytics, and AI MCP, making it easy to integrate Prints data into their own products.

The long-term phase is the most ambitious. It envisions an ecosystem in which undercollateralized lending, governance, and anti-Sybil games all operate on top of the reputation layer. Here, reputation functions not merely as a filter that grants access, but as a key that unlocks new roles and permissions. Undercollateralized lending, a long-standing aspiration in crypto, is particularly noteworthy. Just as credit scores in traditional finance enable lending without collateral, once on-chain reputation has been sufficiently accumulated and verified, it opens the possibility of maximizing capital efficiency without excessive overcollateralization.

What makes this roadmap feasible is a three-layer infrastructure stack comprising Prints, API and oracle services, and software development tools. At the base, Prints serves as the layer that aggregates social capital and reputation data. Above it, API and oracle services provide the interface through which external applications can reference this data. At the top, the SDK minimizes integration costs for builders. Reputation is being designed not as a feature of individual applications, but as shared infrastructure for the entire ecosystem.

4. Potential Use Cases for Fluent

When it comes to the reputation ecosystem, Fluent is clearly still in its early stages. But the possibilities that open up as this infrastructure matures are scenarios in which reputation functions not as a decorative profile element but as a real economic variable on-chain.

This section examines use cases that demand the ability to combine and verify data scattered across different ecosystems within a single execution environment, use cases where, in my view, the blended execution environment can fully realize its potential as reputation infrastructure.

4.1 Agent Reputation

An environment in which AI agents autonomously trade and collaborate on-chain is arriving rapidly, and in this environment, the binary question of "bot or not" is becoming increasingly inadequate. The important question is not "Is this agent human?" but "How trustworthy is this agent?"

ERC-8004 represents the recognition of this need at the standards level. Recently deployed on mainnet, ERC-8004 defines three registries that record an agent's identity, reputation, and verification on-chain. When a client agent records scores, tags, and evidence URIs about a server agent, other smart contracts can read this reputation data and use it in their decision-making. The standard explicitly contemplates scenarios in which a lending protocol references an agent's reputation score to determine a risk premium, or a task marketplace uses it to decide whether to hire an agent.

ERC-8004 also includes meaningful design considerations for cross-chain environments. Agents can register on multiple chains simultaneously, and the registration file on each chain can cross-reference the full list of registries where the agent is registered. As a result, the discovery and lookup of reputation already functions on a cross-chain basis.

However, given the reality that agent activity is distributed across multiple chains, a gap persists between discoverability and economic utilization. Consider the following concrete scenario. Suppose Agent A has vault performance data from 12 months of curation on Ethereum's Morpho, a risk management track record accumulated on Solana's Kamino, and client feedback on tasks completed on Base. Under ERC-8004's current design, these three datasets exist independently on their respective chains, and external systems can query them through cross-references in the registration file.

But if a lending protocol wants to dynamically apply a specific collateral ratio to this agent, it needs to read all three datasets within a single transaction, assign weights to combine them, and reflect the result directly in the lending logic within that same transaction. If this process is routed through an off-chain aggregator, the problems of composability and verifiability resurface. This is not a flaw of ERC-8004. ERC-8004 is a standard for "what to record," and it fulfills that role precisely. What is missing is a layer capable of integrating the recorded data at the execution level in a multi-chain environment. If ERC-8004 has defined the grammar of reputation, what is needed is an execution environment that can interpret the sentences written in that grammar within a single context.

Fluent's blended execution environment has the architecture to bridge this gap. Because EVM, SVM, and Wasm-based contracts can interact atomically within the same execution environment, it is technically possible to read, combine, and prove agent feedback data accumulated across different VMs within the same execution context. This is not a replacement for ERC-8004, but a complementary infrastructure that transforms the data ERC-8004 defines into an economically actionable form.

4.2 Yield Curator Reputation

In the current structure of DeFi lending markets, curators play an essential role. Protocols such as Morpho and Euler have adopted a structure in which risk management is separated from the protocol itself at the vault level and delegated to independent specialists, the curators. Each curator designs a liquidity vault, decides which collateral assets to accept and which markets to allocate funds to, and earns fees based on performance.

Source: Morpho

And yet the methods available for evaluating the trustworthiness of curators who manage these vast amounts of assets are surprisingly primitive. Even Morpho's official documentation advises users to "follow their X account and review public channels" and "check whether they communicate during volatile periods," guidance that relies entirely on manual effort from users. The primary reason is the absence of a verifiable, standardized reputation framework capable of collecting and evaluating all of this information in one place.

This is where the need for a blended execution environment becomes concrete. Leading curators are already active across multiple ecosystems. Curators managing large pools of liquidity, such as Steakhouse and Re7 Labs, are already curating vaults in multi-chain environments spanning Ethereum, Solana, and beyond. To fully evaluate a curator's capability and trustworthiness, their vault performance on Ethereum, their risk management track record on Solana, and their response history during extreme market conditions must all be unified into a single profile. Today, however, this data is distributed across different chains and different VMs, and no infrastructure exists to weave it into a single verifiable reputation. This is an area where the blended execution environment has a clear role to play.

5. Closing Thoughts

The Maghribi traders' letter network, the Law Merchant of the Champagne fairs, the modern credit bureau's FICO score. The direction of evolution running through the history of reputation systems is consistent: from one-dimensional information to multi-layered information, from reputation bound to a specific marketplace to portable reputation, and toward resolving the uncertainty of identity.

The crypto ecosystem's reputation systems will need to follow the same trajectory. Existing reputation protocols such as Kaito, DegenScore, and Galxe have validated the market's fundamental demand for filtering out Sybils and identifying genuine users, and they have established themselves as essential tools for airdrop allocation and community curation. Yet the impact they have generated has remained confined within their respective ecosystems, and they have not changed the cost structure that forces every project to rebuild its own pipeline from scratch. What Fluent is targeting is precisely this gap: by making the economic value that individual protocols have demonstrated integrable, verifiable, and portable on top of a blended execution environment, it aims to elevate reputation from an application-level feature to shared ecosystem infrastructure.

An ecosystem in which real users are rewarded, real communities are recognized, and real contributions accumulate is not a matter of better algorithms. It is a matter of better infrastructure. And the design of that infrastructure is just getting started.