Software often compresses complicated ideas into simple labels: verified, approved, secure, audited, safe. In blockchain systems, those labels can carry enormous weight.
The real problem
A smart contract may control real assets, execute transactions automatically and continue operating long after the people who originally deployed it have moved on. Yet users are often expected to interpret its reliability through a badge, a logo or a short statement saying that something has been checked.
Deploying software on-chain changes the consequences of getting things wrong. Transactions may be irreversible. Assets may be controlled by code. Administrative privileges may themselves create new risks.
The important question is not simply whether a contract works. It is whether people can understand what was deployed, how it was reviewed, what assumptions it relies on, who retains control and what happens when something goes wrong.
What existing approaches get wrong
Trust is often presented as a final state. A contract is audited. A project is verified. A deployment is approved. The complexity that produced that conclusion disappears behind the label.
An audit is not the same thing as a guarantee. Verification does not mean the system is economically sound. A technically correct contract can still rely on unsafe assumptions, and code can change after a previous review.
The problem is not that labels are useless. The problem is treating the label as the evidence.
The principle guiding MODULR
Trust should be inspectable.
If a deployment is being presented as trustworthy, a user should be able to understand why. What code was reviewed? What version was deployed? What tests were performed? What assumptions were made? What permissions remain? What evidence connects the reviewed artefact to the deployed contract? What has not been checked?
These questions turn trust from a marketing claim into a workflow. And importantly, the workflow can expose uncertainty rather than concealing it.
A system saying we do not know is often more useful than one displaying a green tick without explaining what that tick means.
What Ex Parvis is testing
MODULR is exploring how deployment evidence can be organised into something developers, reviewers and users can actually inspect. The harder problem is connecting the pieces: source code, build outputs, tests, review findings, deployment parameters, contract addresses, administrative permissions, governance decisions and changes over time.
If these exist as disconnected artefacts, the person relying on the deployed system has to reconstruct the story themselves. MODULR is testing whether that story can become part of the deployment process.
Not because every user will inspect every detail. But because important claims should remain verifiable by someone who chooses to. That accountability changes how the system is built.
- Source-matched code and build inputs.
- Validator and test results.
- Audit material and review findings.
- Deployment parameters and contract addresses.
- Administrative permissions and governance decisions.
- A record of what changed over time.
What remains uncertain
There is no process capable of proving that complex software is completely safe. Formal verification can establish specific properties under specific assumptions. Testing can increase confidence. Auditing can identify problems. None of these eliminate uncertainty.
Smart contracts also exist inside broader systems. Oracles can fail. Dependencies can change. Keys can be compromised. Economic incentives can behave unexpectedly. Governance itself can become hostile.
Safe is easier to communicate than a precise boundary around what was reviewed, under which assumptions and what remains outside the assessment. But the second statement is much closer to the truth.
We will not claim that MODULR can certify that a smart contract is safe. It cannot. The objective is to make the chain of reasoning clearer: what was checked, what passed, what failed, what changed, who approved it and what remains outside the boundary. When software controls something important, trust should not be something the interface asks you to assume. It should be something the system helps you examine.