Back to blog
PrivacyMAY 2026

The default you can
prove without seeing.

Encrypt's FHE oracle computes loan default conditions on sealed borrower data — no plaintext ever leaves the borrower's control. The on-chain result is a cryptographic proof, not a financial disclosure.

The problem

A public ledger is a terrible place for credit data.

PRISM runs on Solana — a public blockchain where every instruction, every account state change, and every payment is permanently recorded and indexed. That is the source of its transparency and composability. It is also the source of a real problem for institutional credit.

Credit is fundamentally about information asymmetry. A borrower's repayment history, outstanding balances, and default behavior are exactly the data their competitors, counterparties, and rivals would pay to see. Posting that data on-chain to trigger a default is not an acceptable tradeoff for any serious institutional borrower.

  • Loan balances and repayment history are permanently indexed.
  • Borrowers competing in the same market expose their cash flow to rivals.
  • No institutional credit desk will borrow on a chain that makes their liabilities public.
  • Admin-triggered defaults require trusting a human, not a proof.

Without a solution to this, PRISM's credit market is limited to borrowers with no privacy requirements. That is a small market. The real institutional credit market requires something better.

Encrypt + FHE

Compute on the ciphertext. Never touch the plaintext.

Fully Homomorphic Encryption (FHE) is a class of cryptographic scheme that allows arbitrary computation on encrypted data. The operator running the computation never decrypts the input — they work entirely on ciphertext — yet the output is a cryptographically correct answer to the query.

Encrypt implements a REFHE variant optimized for range proofs and boolean conditions. For PRISM's default use case, the relevant circuit is simple: does total_repaid < principal? That single boolean, proven over sealed inputs, is all the on-chain program needs to trigger the loss cascade.

  • Computes on ciphertext — the oracle never sees plaintext values.
  • The result is a provable boolean, not a data disclosure.
  • Any tampering with the sealed data produces a commitment mismatch.
  • The proof is deterministic — the same sealed data always yields the same result.

The oracle is a prover, not a data relay. It receives the sealed credit data, runs the FHE circuit, and outputs a signed boolean. The borrower's raw repayment numbers never appear anywhere in the transaction.

The flow

From sealed data to on-chain cascade.

PRISM's Encrypt integration has two phases separated in time: commitment at underwriting, and verification at default.

When a loan is underwritten, the attach_encrypt_score instruction creates an EncryptLoanHealth PDA on-chain. This PDA stores the score_commitment — a sha256 hash of the borrower's Encrypt-sealed credit data. The sealed data itself lives with the Encrypt oracle. Only the commitment goes on-chain. That commitment is the anchor.

When default is suspected, the Encrypt oracle loads the sealed data, runs total_repaid < principal homomorphically, and signs a 73-byte attestation message. The signature and message are submitted to Solana in a two-instruction transaction.

73-byte attestation layout
0 – 78 bytesb"enc_atts"Fixed prefix
8 – 3932 bytesloan pubkeyWhich loan is attested
40 – 7132 bytesscore_commitmentsha256 of sealed credit data
721 byteresult: 0x01Default proven = true

The first instruction in the transaction is the native Ed25519 precompile — Solana validates the oracle signature at the runtime level, with no program logic involved. The second instruction, verify_encrypt_default, reads the precompile's result through the instructions sysvar, validates the commitment matches the one registered at underwriting, checks the result byte is 0x01, and fires the loss cascade.

Commitment binding

The sha256 anchor.

The score_commitment stored at underwriting time is the binding mechanism that prevents oracle substitution attacks.

Suppose an adversary wanted to trigger a false default on a healthy loan. They would need to produce a valid Ed25519 signature from the Encrypt oracle over a message whose commitment field matches the one stored in EncryptLoanHealth. That requires either controlling the oracle private key or finding a preimage to the sha256 commitment — both computationally infeasible.

The same binding works in reverse: the oracle cannot attest a default based on different credit data. Any substitution produces a different sha256 hash, which fails the commitment check in verify_encrypt_default with a hard rejection.

The commitment ties the FHE computation to exactly the data that was sealed at underwriting. The oracle has no latitude to run the circuit over different inputs and still get a passing result.

What changes

A default that institutions can accept.

Without FHE
  • Default requires admin to post loan balance and repayment amount on-chain.
  • Every credit event permanently exposes borrower financial data.
  • Institutional borrowers refuse the model — too much disclosure risk.
  • The trust problem shifts from collateral to the oracle operator.
With FHE
  • Default is proven by a cryptographic circuit, not a data post.
  • The on-chain record is a commitment hash — no raw financial data.
  • The loss cascade fires from a proof, not an admin transaction.
  • Institutions can borrow without their credit profile becoming public.

The loss cascade is identical either way. Alpha absorbs first, then Core, then Prime. The waterfall does not change. What changes is how the cascade is authorized: not by an admin posting sensitive data, but by a proof that a condition is true.

Why it matters

Privacy is what makes trustless credit possible.

The combination of Encrypt and IKA solves the two hardest problems in on-chain institutional credit at the same time. IKA handles the collateral problem — BTC and ETH locked without a custodian. Encrypt handles the disclosure problem — defaults proven without exposing financial data.

Together they enable a credit market that works the way institutional credit actually works: where collateral is cryptographically secured, where default events are provably triggered, and where borrower financial profiles are not permanently indexed on a public ledger for their competitors to read.

FHE is not a privacy feature that PRISM added to check a box. It is the mechanism that makes the default path acceptable to the borrowers PRISM is built for. Without it, the credit market is limited to actors with no privacy requirements — a small and uninteresting market. With it, the market is every institution that needs credit on-chain and could not take the disclosure risk before.