Most DeFi lending still runs on overcollateralized structures. To borrow 100, a user must first deposit more than 100 in value. The reason is simple. Lending is a transaction with a time gap between capital provided now and repayment made later. Traditional finance fills that gap with credit. DeFi fills it with collateral. The problem is that collateral is inefficient. Capital is locked up, and the borrowing limit is always smaller than the value of the assets posted. So around 2022, the industry naturally moved toward a question: “if credit could exist onchain, could this inefficiency be reduced?”
A leading example of that line of thinking was Spectral Protocol. At the time, it drew industry attention after raising $30 million from major institutions such as Samsung Next, Circle Ventures, Franklin Templeton, and Jump Capital. Samsung Next summarized its investment thesis as follows.
"A DeFi solution for credit risk assessment has important implications for financial institutions. While web3 smart contracts and loan decisions can be made almost instantaneously, DeFi loans are often over-collateralized to compensate for the lack of a reliable tool for assessing credit risk on-chain. The ability to assess credit risk is essential for DeFi, in which financial institutions rely on inherently trustless, open source applications to make lending decisions."
That expectation did not last long. In 2024, Spectral shifted toward onchain AI agent infrastructure centered on SYNTAX through its public roadmap and product launch. Its official site now describes the company as infrastructure for the agent economy, and onchain credit scoring has largely faded from view.
For a broader discussion of web3 reputation projects, see "The Rise of web3 Reputation"
Why did it fail? The answer comes down to three factors: enforcement, identity, and continuity.
Enforcement: Even if a borrower defaults, there is no legal mechanism inside the chain to enforce repayment.
Identity: Wallet addresses start from anonymity by default, and there is no clear way to collect the data needed to build identity.
Continuity: It is hard to bind records scattered across multiple wallets into one stable identity.
Credit works in the real world because three elements exist together: an identity that cannot simply be discarded, a cumulative record, and legal enforcement when default occurs. The reason these elements are needed is also clear. Human behavior is unpredictable. A person who repaid faithfully 100 times may still disappear on the 101st. That is why traditional finance accumulates past records, uses them to estimate future behavior probabilistically, ties those records to identity so they cannot be reset, and still places legal enforcement behind the system on the assumption that someone may still walk away.
Onchain, by contrast, all three pillars were weak. If a credit score fell, a user could switch wallets. Without legal enforcement, the practical cost of ignoring a debt was limited. Recently, projects such as 3Jane Protocol (@3janexyz) have tried to combine onchain and offchain credit assessment with legal recovery procedures in the United States. That actually makes the point clearer. A purely onchain system has difficulty completing debt enforcement on its own. In its whitepaper, 3Jane mentions both onchain and offchain credit assessment. In its FAQ, it separately explains the possibility of recovery through courts, arbitration, and collection agencies.
In the end, an onchain credit score may help estimate risk, but it does not easily become collateral that prevents losses or a mechanism that enforces claims.
Source : X(@virtuals_io)
ERC-8183, jointly proposed by Virtuals Protocol (@virtuals_io) and the Ethereum Foundation's dAI team, defines jobs, escrow, evaluators, and hooks as the minimum units for agentic commerce between agents. The core idea is simple. Rather than bridging the time gap in a transaction by predicting the other party's future behavior, it creates a structure in which the transaction does not collapse even if one party defects.
Source : Ethereum Improvement Proposals
At the center of ERC-8183 is a simple requirement. Each transaction is treated as a Job, and work cannot proceed until the client places the budget in escrow. In the specification, state transitions move from Open to Funded to Submitted, and then to terminal states such as Completed, Rejected, and Expired. In the Funded state, the budget is already locked in escrow. In other words, this structure does not ask whether the other party will pay later. It starts from the premise that the money is already locked.
Source : Ethereum Improvement Proposals
The next problem is quality. Locked funds do not automatically guarantee the quality of the output. ERC-8183 leaves that judgment to the Evaluator. The specification states that, once a Job is in Submitted, only the evaluator may call complete or reject. What ERC-8183 removes, then, is not trust itself but mutual trust between the parties to the transaction. The weight now shifts to a single point: the evaluator. Instead of forcing human credit into agents, it completes the transaction through escrow and an evaluator's decision. Trust has been moved to a different place in the system.
Source : Ethereum Improvement Proposals
This structure also has a weak point. The evaluator may behave maliciously. The Security Considerations section of ERC-8183 says so directly. The document notes that, after Submitted, the evaluator can process completion or rejection arbitrarily, and it recommends reputation systems or staking, such as ERC-8004, for higher-value transactions. At the same time, the document does not include dispute resolution or arbitration in the core, and it states that rejection or expiration is final. In other words, the main risk is identified, but much of the response is left to external layers and later design choices. ERC-8004 itself is also still a draft and is closer to a proposal for a trust layer built around an identity registry, a reputation registry, and a verification registry.
Even so, the approach still has value. If onchain credit scoring failed because it tried to convert human reputation directly into a number, ERC-8183 applies reputation in a narrower way, to the evaluator rather than to the counterparty. Here, reputation is not a score that predicts whether someone will be honest in the future. It is closer to a record of how many cases an evaluator has handled and how much dispute has followed. That kind of record does not guarantee trust, but it can still inform selection. The ERC-8183 document also keeps reputation and validation logic outside the core, separating them through Hooks and integration with ERC-8004.
In practice, a certain degree of centralization among evaluators is hard to avoid in the early stage. A small number of verified evaluators need to handle arbitration and accumulate decisions and records before later participants have a basis for reference.
As more participants enter a system built on carefully designed incentives and slashing mechanisms, malicious behavior becomes harder to maintain. The blockchain consensus process offers a familiar comparison. A 51% attack is theoretically possible, but it rarely occurs in practice, because the cost of the attack exceeds the available gain. The same logic applies to evaluators. Once decision histories accumulate, and once fees and transaction opportunities concentrate around honest evaluators, the value of the reputation built through honest conduct becomes greater than the gain from sacrificing that reputation in a single collusive act. The incentive to defect falls as a matter of structure.
ERC-8183 is not a finished system. It is a direction. Still, the design principle behind that direction is clear. Escrow guarantees execution of the transaction. Reputation provides a basis for choosing the mediator. Incentives make honest behavior the rational choice. If onchain credit scoring failed because it tried to transplant human trust into an onchain system, ERC-8183 asks a different question: did trust need to be transplanted at all? Would it not be better to build a new structure from the start, one that fits the onchain environment?
Virtuals
