This article is translated by the Reactive Network Chinese community. The technical facts and boundaries are subject to the original text.

Original text: https://blog.reactive.network/veritas-keeping-a-risk-score-true-as-copies-appear/

Veritas is the sixth and final project among the six introduced in the UHI9 Hookathon. It applies reactive contracts to a scenario not previously addressed by other projects: ensuring that the values stored on-chain remain accurate even as the objects being measured silently change. The complete project code is hosted on GitHub, but the repository is currently private, and access may need to be requested from the owner. The project website can be viewed here.

Veritas is a Uniswap v4 Hook that serves a tokenized content liquidity pool. Tokenized content can be a photo or other media content that has been registered on-chain and established a liquidity pool around it.

It is meant to price a type of risk that ordinary liquidity pools usually overlook: as copies and approximate copies of content proliferate, the scarcity upon which the original depends for its value will be diminished, ultimately resulting in losses borne by the liquidity providers in the pool—those who deposit two tokens for others to exchange.

Veritas assigns a risk score to each asset and incorporates it into the liquidity pool's exchange fees: the higher the asset risk, the higher the fee, and the compensation for liquidity providers for assuming the risk increases accordingly. The truly interesting part, and the reason why Reactive is involved, lies in when this risk actually changes.

● ● ●

01

Risks from Elsewhere

For ordinary automated market makers, a liquidity pool holding a unique photo looks identical to one holding ten thousand identical copies. It cannot identify scarcity, and therefore cannot price the losses caused by the decline of scarcity.

As copies increase, the price of the content will shift, and liquidity providers will bear the resulting differential, which is referred to as impermanent loss: after price changes, the final situation for liquidity providers will be worse than simply holding two types of tokens. Veritas measures the extent to which content has been diluted, compiles it into a singular risk score, and then allows the liquidity pool fee to adjust according to this score.

However, there is a part of the work that the Hook cannot accomplish independently. The degree of dilution of content changes not because of what this content or its liquidity pool itself has done, but because someone elsewhere has registered an approximate copy.

Imagine creating proof for an original photo today—registering it on-chain along with its image fingerprint—so its copy count is zero. Next week, an approximate copy is registered, and without any event occurring to the original, it suddenly becomes less scarce than it was before.

The liquidity pool has had no transactions, hence the Hook doesn’t run; there is no reason for anyone to send a transaction to go back and update the record of the original. The value that was originally used to represent its risk quietly distorts.

● ● ●

02

What Reactive Contracts Monitor

Every new piece of content is recorded in the registration contract on Unichain. When registration occurs, the registry emits a NewAttestation event.

Veritas's reactive contract DilutionMonitorRC is deployed on Reactive's Lasna testnet and subscribes to every such event issued by the registry, as any new proof could potentially be an approximate copy of some existing content.

The projects previously introduced in this series subscribed to events related to individual liquidity pools. In contrast, Veritas subscribes to the emergence of new content across the entire registry because the risks faced by existing assets stem from here.

Veritas Dilution Risk Score Update Process

In the diagram, DRS refers to the dilution risk score of the liquidity pool (Dilution Risk Score): it is a single value between 0 and 1, used to indicate the copying risk faced by a piece of content, and is also the metric tracked by the liquidity pool fee.

The number of copies on-chain is one of its inputs. Thus, the more approximate copies of a piece of content appear, the higher the copy count becomes, the DRS rises, and the fees charged by the liquidity pool will increase to compensate for the risks undertaken by liquidity providers.

The purpose of the entire cycle is to keep this count updated when new copies appear: the registry emits proof events; the reactive contract on Lasna detects the event and forwards the ID of the new proof; then, the callback back to Unichain finds the existing approximate copies and increases their count.

● ● ●

03

From New Proof to Liquidity Pool Repricing

After the new proof arrives, react() will run. It intentionally does only one small thing: forwards the ID of the new proof to a callback on another chain, that’s all. It doesn’t conduct the search for copies itself.

Reactive contracts operate in a constrained environment, making it impossible to read the content fingerprints stored on the target chain at a low cost, so the comparison work is left to the side better suited for executing it.

The real work occurs in the callback on the target chain. It reads the fingerprint of the new content, queries the registry for existing records that are similar enough to be identified as approximate copies, and then increases the dilution count for each affected existing record.

This callback only listens for calls sent from the official Reactive callback agent, and the registry only accepts counting increase requests from this callback. Therefore, the only contract authorized to raise the asset risk is the contract at the end of this complete invocation chain.

The count increase will drive the score change: a higher dilution count will elevate the risk score, and the liquidity pool will read the new score, immediately charging a higher fee during the next exchange.

This way, if a copy appeared quietly last week, causing liquidity providers to bear additional risks, they do not need to operate manually; they can still receive more compensation for continuing to bear this risk. Each count increase is encapsulated separately, so even if a record is frozen or is in dispute, it will not block other records in the batch.

04

About Reactive Network

Reactive Network is an EVM automation layer built on reactive contracts. Reactive contracts are a type of event-driven smart contract designed for cross-chain and on-chain automation.

The network uses CometBFT consensus, providing immediate finality and approximately 1-second block time while maintaining full EVM compatibility.

Reactive contracts can subscribe to event logs across multiple EVM chains. When matching events occur, they automatically execute Solidity logic and autonomously decide when to send cross-chain callback transactions. This model supports conditional cross-chain state changes, as well as ongoing cross-chain workflows.

🔗 Relevant links in the original article

[1] https://reactive.network/
[2] https://blog.reactive.network/
[3] https://x.com/0xreactive
[4] https://t.me/Reactive_Network
[5] https://discord.com/invite/SaZAfkgZhj
[6] https://dev.reactive.network/

One build—everywhere responsive!
How to join the Reactive Network Chinese community?
👉 Please add the operator's WeChat (Alc142) and note【Reactive Network Chinese Community】

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。