> For the complete documentation index, see [llms.txt](https://stoxfi.gitbook.io/stoxfi-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://stoxfi.gitbook.io/stoxfi-docs/fully-homomorphic-encryption-and-confidentiality.md).
# Fully Homomorphic Encryption & Confidentiality
Confidential execution is the core mechanism that allows StoxFi to hide balances and transfer amounts while continuing to process financial state onchain.
Within ConfidentialStock, balances are not stored as ordinary public integers. They are represented as encrypted `euint64` values.
This allows StoxFi to perform calculations directly on encrypted data without first exposing the underlying value.
### Encrypted Balance Model
Each account has an encrypted balance maintained by ConfidentialStock.
The balance is represented as:
`euint64`
The confidential representation uses 6 decimals.
Unlike a standard ERC 20 balance, the plaintext value is not publicly readable from contract storage.
StoxFi performs the required balance operations through the FHE layer while the values remain encrypted.
### Confidential Transfer Architecture
**StoxFi FHE and Confidentiality**
The confidential transfer process begins with encryption in the user's browser and ends with updated encrypted balances and access permissions.
The transfer amount itself is never decrypted during the transfer.
### Creating an Encrypted Input
Before a confidential transfer is submitted, the requested amount is encrypted in the browser.
The application creates an encrypted input for the ConfidentialStock contract and the sending user.
The resulting encrypted input includes a ciphertext handle and an input proof.
The proof binds the encrypted value to the intended contract and sender.
ConfidentialStock validates this input before using it in an encrypted operation.
### Computing on Encrypted Values
StoxFi uses encrypted operations to determine whether a transfer can proceed.
The contract evaluates whether:
1. The requested amount is less than or equal to the sender's encrypted balance
2. The requested amount can be added to the recipient's encrypted balance without exceeding the supported range
These conditions are evaluated without exposing the underlying values.
The resulting encrypted conditions determine whether the requested amount or zero should move.
If both conditions are satisfied, the encrypted transfer amount is selected.
If either condition is not satisfied, encrypted zero is selected.
The selected value is then subtracted from the sender and added to the recipient.
At no point does ConfidentialStock need the plaintext transfer amount to perform this operation.
### Silent Zero Transfers
A conventional token transfer may revert when a sender does not have enough balance.
For a confidential balance system, that behavior could reveal information.
If an observer knows the requested amount and sees whether the transaction succeeds or fails, the result can expose information about the sender's balance.
StoxFi avoids this by using encrypted selection.
An invalid confidential transfer can complete while moving zero.
This means transaction success alone does not reveal whether the sender held the requested amount.
The public observer therefore cannot determine whether the confidential transfer moved the requested value or silently moved zero.
### Encrypted Arithmetic
The encrypted operations used by StoxFi include:
`FHE.add`
`FHE.sub`
`FHE.le`
`FHE.lt`
`FHE.and`
`FHE.select`
`FHE.asEuint64`
`FHE.fromExternal`
These operations allow ConfidentialStock to perform the arithmetic and conditional logic required for balance management without converting the confidential values into plaintext.
### Access Control
Encrypted values are controlled through access permissions.
After a confidential balance is created or modified, StoxFi grants the permissions required for the contract and relevant user to continue using that encrypted value.
For a confidential balance, the holder is permitted to decrypt their own balance.
For a transferred encrypted value, access is granted to the sender and recipient.
The encrypted total supply is accessible to the contract owner rather than public observers.
These permissions are managed through the FHE access control layer.
### Balance Decryption
A user's confidential balance is not publicly decryptable.
The holder can request private decryption through a request scoped to their address.
This allows the user to view their own confidential position without making the balance public onchain.
Public observers do not receive the same permission.
### Redemption Is Different
Redemption requires a different confidentiality boundary.
StoxVault ultimately needs a public quantity in order to release an exact amount of the underlying ERC 20.
For this reason, the encrypted amount burned during redemption is deliberately made publicly decryptable.
The FHE layer processes the public decryption request and returns the clear amount together with threshold signatures.
ConfidentialStock then verifies those signatures against the encrypted handle and clear value.
Only after successful verification can StoxFi dispatch the cross chain release instruction.
Nothing is decrypted directly onchain.
The blockchain verifies the signed result of the external threshold decryption process.
### Who Can Decrypt What
| Encrypted Value | Decryption Access |
| ---------------------------- | -------------------- |
| User balance | Balance holder |
| Confidential transfer amount | Sender and recipient |
| Encrypted total supply | Contract owner |
| Redemption amount | Publicly decryptable |
The redemption amount is intentionally different from an ordinary confidential transfer because it must ultimately correspond to a public release of underlying collateral.
### What Remains Confidential
During confidential settlement, a public observer cannot determine:
1. A user's confidential balance
2. The amount transferred between users
3. Whether a transfer moved the requested value or encrypted zero
4. How a shielded position was divided across subsequent confidential transfers
5. The encrypted total supply
The blockchain still records that an interaction occurred.
Addresses and transaction timing remain visible.
The confidentiality applies to the financial values rather than the existence of the transaction.
### Transfer Events
A confidential transfer emits:
`ConfidentialTransfer(from, to)`
The event contains the sender and recipient.
It does not contain the transferred amount.
This preserves public visibility of the interaction while keeping its financial value encrypted.
### Confidentiality Boundary
The FHE layer does not make the entire StoxFi lifecycle confidential.
Shield amounts remain public because the underlying ERC 20 deposit is public and the mint instruction carries the amount in cleartext.
Unshield amounts become public because the burned encrypted amount must be decrypted before the underlying collateral can be released.
The confidential portion exists between those two public boundaries.
Within that interval, StoxFi can maintain encrypted balances and execute transfers without revealing their amounts.
This is the confidentiality model at the center of StoxFi.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://stoxfi.gitbook.io/stoxfi-docs/fully-homomorphic-encryption-and-confidentiality.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
