Encrypted contracts need rules for evidence and disclosure

Fhenix’s October 20, 2026 technical note examines security when contracts compute with encrypted values. Its useful contribution is to bring application design into a discussion often dominated by cryptography. Fhenix technical note

For a business considering a confidential onchain application, the first decision is what other participants should be unable to learn. The next is what those participants must still be able to verify. These requirements can pull in different directions. A procurement process may need to conceal competing bids while demonstrating that the published selection rule was followed. Hiding the bids does not answer who wrote that rule, who may change it, or who can inspect the outcome after a dispute.

This article offers an analytical framework rather than a security assessment of a particular deployment. The distinction matters: an architecture document establishes a design claim, not the absence of implementation defects, and a research paper about a class of systems does not establish a vulnerability in a named product.

A private bid still needs a public rule

Consider a hypothetical buyer using an encrypted procurement auction. Suppliers submit prices that competitors cannot read. The buyer wants the cheapest offer satisfying delivery and quality requirements. There is an obvious commercial reason for confidentiality: a supplier should not have to reveal its entire pricing strategy merely to compete for one contract.

Yet the lowest numerical bid need not be the correct business outcome. A supplier may quote in the wrong currency, omit shipping or promise an incompatible delivery date. Even flawless encrypted arithmetic can compare inputs that should never have been compared. The application therefore needs a definition of an eligible offer before the computation starts. Encryption cannot decide whether a delivery promise is credible or whether the specification reflects what the buyer actually needs.

The same issue appears at the output. A buyer might need only the winning supplier and final payable amount. Giving every participant the full ranking could expose more commercial information than the process requires. Conversely, revealing too little may prevent a losing supplier from challenging an inconsistent decision. The suitable disclosure policy follows the transaction’s purpose, including its dispute process; it is not determined by the choice of cryptographic primitive.

Separate a valid computation from a valid decision

A January 17, 2023 research paper, Verifiable Fully Homomorphic Encryption, treats computation integrity as a separate problem and studies protections against malicious execution. It is historical technical research, not a finding about today’s CoFHE implementation. Research paper

For the hypothetical auction, this suggests distinguishing two kinds of assurance. Technical verification asks whether the specified operation was performed on the specified inputs. Business review asks whether those inputs and that operation represented the agreed procurement rule. A proof of the first cannot silently stand in for the second. An encrypted comparison that accurately implements an outdated eligibility rule can still produce a commercially unacceptable winner.

This distinction also changes how evidence should be organized. A useful review record would connect the rule version, the accepted input set, the computation being checked and the result eventually disclosed. A cryptographic check detached from that context may be mathematically meaningful but insufficient to explain a purchase decision. This is an editorial inference about evidence design, not a claim that a particular protocol supplies all those records automatically.

The procurement team also needs to agree who will explain these records before launch. Technical staff may establish what the program did without authority to interpret commercial exceptions. Business managers may explain the purchasing objective without knowing which conditions a proof covers. Assigning both responsibilities to a generic “verified by the system” label makes a later dispute harder to resolve.

Permissions are part of the product

Zama’s current ACL documentation distinguishes lasting ciphertext permissions from access limited to the current transaction. It separately describes permission to make a value publicly decryptable. These are different application choices. Zama ACL documentation

A procurement team can use that distinction to make its own requirements precise without assuming that all platforms implement identical controls. A calculation service may need temporary access for one job. An auditor may need a defined view for a specified engagement. A customer-support employee may need only enough information to resolve an individual ticket. Granting all three roles the same broad entitlement would simplify administration while weakening the reason for making the application confidential in the first place.

The scope of a permission also needs to survive ordinary organizational changes. A supplier changes its account, an auditor’s contract ends, or the buyer replaces an outsourced operator. The design question is not merely whether access can be granted. It is whether the team can identify the affected data and understand what a change will and will not accomplish. Ending future access cannot make a recipient forget plaintext it has already obtained. Exported reports and screenshots therefore belong in the operational privacy discussion even if the underlying computation remains encrypted.

Permission review cannot end at initial integration. A service originally intended only to display results may later add analytics or exports. That change need not be a technical malfunction, but it can change which people and systems encounter the data. The organization needs to recognize the changed business scope before deciding whether authorization should change, rather than relying indefinitely on an earlier review.

Examine the system that exists today

CoFHE’s current Teecryptor documentation describes decryption inside an attested trusted execution environment. It presents multiparty threshold decryption as a planned replacement. The present design and the roadmap should not be conflated. CoFHE Teecryptor documentation

That qualification is not an argument against deploying a system with hardware assumptions. Businesses routinely accept technical dependencies when the benefit justifies them. It is an argument for comparing actual dependency sets rather than marketing categories. A buyer should understand which component must remain available, what evidence supports its operation, and what happens when the necessary service cannot produce a result.

For the auction, an unavailable result could delay an award even if no bid is exposed and no arithmetic is wrong. A predetermined postponement or cancellation procedure may be more valuable than an improvised emergency disclosure. Such a procedure has a commercial cost: suppliers may have to keep capacity available longer. Confidentiality, availability and contractual timing therefore have to be considered together rather than evaluated by separate teams that never reconcile their assumptions.

The strongest case for encrypted computation is not that it removes every institution from the transaction. It can let parties cooperate without distributing all the underlying data. That is a meaningful benefit where disclosure itself creates a competitive cost. Its value is easier to assess when the application specifies which facts remain hidden, which conclusions can be checked, and which people retain authority over changes and exceptions.

An initial deployment should consequently be judged by a complete transaction and a realistic dispute, not just by an encrypted calculation demonstration. If the buyer can explain a contested outcome without exposing unrelated bids, and can handle a stalled process without abandoning the original disclosure limits, the technology is serving a recognizable business requirement. Whether a particular implementation achieves that remains a matter for evidence and testing, not an implication of the FHE label.