> 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/security-and-trust-model.md). # Security & Trust Model StoxFi combines contract level controls with external infrastructure assumptions. The protocol restricts minting, collateral release, encrypted balance operations, cross chain messages, and redemption through explicit validation rules. At the same time, the system depends on the correct operation of CCIP, the FHE infrastructure, the underlying ERC 20 assets, and the StoxFi owner key. Understanding both sides is necessary to understand the security model. ### Trust Model **StoxFi Security and Trust Model**
The architecture places different responsibilities across StoxVault, ConfidentialStock, cross chain messaging, the FHE infrastructure, the underlying token, and administrative ownership. ### Core Trust Assumptions The current implementation depends on four principal trust assumptions. #### 1. Cross Chain Message Delivery StoxFi depends on Chainlink CCIP for faithful cross chain message delivery. Shielding requires a message from Robinhood Chain to Ethereum. Unshielding requires a message in the opposite direction. StoxFi validates the messages at the contract level, but delivery itself depends on the CCIP infrastructure. #### 2. Confidential Computation Infrastructure StoxFi depends on the correctness of the FHE execution environment and its access control system. Encrypted balances and transfer operations rely on this infrastructure to preserve the confidentiality and correctness of encrypted values. Redemption also depends on the threshold KMS process used to decrypt the burned redemption amount. Compromise of the KMS infrastructure is therefore part of the trust model. #### 3. Underlying ERC 20 Behavior StoxVault assumes that supported underlying assets behave as standard ERC 20 tokens. The accounting model depends on the quantity received by the vault corresponding correctly to the quantity represented confidentially. StoxVault verifies the exact amount received during deposit to reject fee on transfer behavior. Rebasing behavior would break the collateral invariant. #### 4. Owner Key Security The current StoxFi contracts are owned by a single externally owned account. The owner address is: `0x707915D8c13bd78c943e5f3EB97e73E6ef02c6F3` Compromise of this key would expose the administrative functions available to the owner. A multisignature ownership structure is recommended before mainnet deployment. ### Cross Chain Message Security Cross chain messages can cause confidential value to be created or underlying collateral to be released. StoxFi therefore validates inbound messages before processing them. The validation model includes: 1. Router validation 2. Source chain validation 3. Sender validation 4. Replay protection A message must arrive through the expected CCIP Router. It must originate from the expected source chain. Its sender must match the configured StoxFi peer. Its message identifier must not have already been processed. These checks apply to both mint instructions and collateral release instructions. ### Replay Protection Processed cross chain message identifiers are stored by the receiving contract. Once a message has been processed, the same identifier cannot be used again. This prevents a valid mint instruction from creating confidential value twice. It also prevents a valid release instruction from releasing collateral twice. ### Fixed Peer Relationships StoxVault and ConfidentialStock are bound through one time configuration. StoxVault uses `setPeer`. ConfidentialStock uses `setVault`. Once configured, these trust relationships cannot be changed. This prevents an administrator from later redirecting an existing deployment toward a different vault or confidential token. A configuration mistake requires redeployment. ### Mint Security ConfidentialStock has no administrative mint function. The owner cannot directly create encrypted balances. Minting occurs only after a valid cross chain instruction is received from the configured StoxVault. The message must pass the inbound validation checks before confidential value can be created. ### Redemption Security Redemption uses a two stage process. First, the encrypted amount is burned and assigned to a redemption request. Second, the publicly decrypted amount and its proof are submitted for verification. This ordering ensures that the confidential value is removed before collateral can be released. The burned balance cannot remain spendable while the redemption is pending. ### Decryption Verification A clear redemption amount is not accepted simply because a user submits it. ConfidentialStock verifies the signatures associated with the public decryption result. The proof must correspond to the encrypted handle and the claimed clear value. Only after successful verification can the release instruction be dispatched. ### Permissionless Finalization Redemption finalization is permissionless. Another account can submit the finalization transaction for an existing redemption request. However, the destination is fixed when the request is created. A third party can therefore complete a pending redemption but cannot redirect the underlying collateral to another destination. ### Encrypted Underflow Protection StoxFi prevents encrypted subtraction from underflowing. Before applying a requested transfer amount, ConfidentialStock evaluates whether the sender has sufficient encrypted balance. Encrypted selection determines whether the requested value or zero is used. The subtraction therefore operates on a value that has already been limited by the encrypted condition. ### Encrypted Overflow Protection StoxFi also protects encrypted credits from exceeding the supported `euint64` range. The contract evaluates whether the receiving balance has sufficient remaining capacity. If not, encrypted zero is selected instead of the requested amount. Supply limits are also checked during shielding. ### Cross Collateral Protection Collateral is isolated by asset. StoxVault tracks locked collateral for each supported stock. The relationship between an underlying stock and its confidential peer is explicitly configured. A release for one confidential stock therefore cannot draw from the recorded collateral of another stock. ### Exact Receipt Protection StoxVault checks the change in its token balance during a deposit. The amount received must equal the expected amount. This protects the collateral relationship against fee on transfer behavior that could otherwise create more confidential value than underlying collateral. ### Reentrancy Protection StoxVault and ConfidentialStock inherit `ReentrancyGuard`. This provides contract level protection for relevant operations involving token movement and state transitions. ### Pausing StoxVault and ConfidentialStock inherit `Pausable`. The owner can pause and unpause supported operations. This provides an administrative control for responding to problems in the deployed system. ### Owner Capabilities The owner can perform administrative actions including: 1. Registering supported stocks 2. Managing registry listings 3. Pausing and unpausing contracts 4. Sweeping stray native tokens 5. Rescuing eligible non collateral tokens 6. Decrypting the encrypted total supply These capabilities form part of the current administrative trust model. ### Owner Restrictions The owner cannot: 1. Administratively mint confidential balances 2. Repoint configured trust anchors 3. Seize locked collateral through the rescue mechanism 4. Redirect an existing redemption 5. Read individual user confidential balances 6. Upgrade the deployed contract logic These restrictions limit the authority available through contract ownership. ### Immutable Contract Logic StoxFi does not use upgradeable proxies. The deployed contract implementation cannot be replaced through an upgrade transaction. This removes an upgrade authority from the trust model. It also means that a contract defect requiring a code change must be addressed through redeployment. ### Frontend Trust The StoxFi web application is not part of the authoritative state layer. Protocol state remains onchain. However, frontend compromise remains an open risk because users interact with the contracts through the browser application. The current architecture does not eliminate this risk. ### Security Testing The implementation has tested protections covering: 1. Forged cross chain messages 2. Incorrect source chains 3. Incorrect message senders 4. Message replay 5. Unauthorized confidential transfers 6. Double spending during redemption 7. Forged decryption results 8. Redemption replay 9. Encrypted underflow 10. Encrypted overflow 11. Cross collateral drain attempts 12. Fee on transfer undercollateralization 13. Reentrancy 14. Storage griefing The implementation has also been tested against the absence of an upgrade attack path because the production contracts are immutable. ### Audit Status The StoxFi contracts have undergone an internal security review. The review identified: 2 Medium findings 3 Low findings 5 Informational findings Both Medium findings were fixed in the deployed bytecode. A third party audit has not yet been completed. The current status is therefore: **Internally audited. Third party audit pending.** ### Current Ownership Risk All current production contracts are owned by the same externally owned account. This creates a centralization risk around the administrative functions that remain available to the owner. The current technical recommendation is to move ownership to a multisignature structure before mainnet deployment. ### Security Model Summary StoxFi limits value creation and release through explicit contract rules. Confidential minting requires a validated message from the configured vault. Collateral release requires a validated message from the configured confidential peer. Cross chain messages are protected by source validation and replay protection. Encrypted arithmetic is constrained against underflow and overflow. Redemption burns confidential value before collateral release and requires verification of the decrypted amount. At the same time, StoxFi depends on cross chain messaging, the FHE infrastructure, standard underlying token behavior, and secure administration. These dependencies define the trust boundary surrounding the protocol's contract level protections. --- # 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/security-and-trust-model.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.