> 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/limitations-and-risks.md). # Limitations & Risks StoxFi has a complete testnet implementation of its core confidential settlement lifecycle, but several technical, operational, security, and privacy limitations remain before production deployment. These limitations define the current boundaries of the protocol. ### CCIP Allowlist Dependency The most immediate operational constraint is CCIP sender allowlisting. The Ethereum mainnet to Robinhood mainnet CCIP lane exists, but its sender allowlist is enabled. StoxFi sending contracts therefore require approval before they can use this lane. The current testnet lanes are also allowlisted in both directions. This limits open access to the complete cross chain lifecycle. The current mainnet constraint is therefore not the availability of fully homomorphic encryption on Ethereum. It is access to the required CCIP messaging lane together with the remaining mainnet configuration and deployment work. ### Reverse Mainnet Lane The Robinhood mainnet to Ethereum mainnet CCIP direction has not been verified. StoxFi requires communication in both directions for the complete lifecycle. Shielding requires communication toward the confidential environment. Redemption requires communication back toward the collateral vault. The availability and configuration of the reverse mainnet direction therefore remains an unresolved requirement. ### CCIP Trust StoxFi depends on CCIP for cross chain message delivery. The contracts validate the router, source chain, sender, and message identifier, but they still rely on the underlying messaging infrastructure for faithful delivery. A failure or disruption in cross chain messaging can interrupt shielding or redemption progression. StoxFi does not currently implement a custom CCIP retry or recovery system. ### FHE Infrastructure Trust Confidential balances and transfers depend on the correctness of the FHE execution environment. StoxFi also depends on its access control system to enforce permissions over encrypted values. A failure in this infrastructure could affect the confidentiality or correctness of encrypted state. ### KMS Trust Redemption depends on threshold decryption. The burned redemption value is made publicly decryptable and the KMS infrastructure produces the clear value and signatures required for verification. Compromise of this infrastructure is therefore part of the StoxFi trust model. The exact KMS committee size, operator composition, and collusion threshold have not been independently verified for this implementation. StoxFi does not make claims about those specific parameters. ### Administrative Key Risk All current StoxFi contracts are owned by one externally owned account. This creates a centralization risk around the administrative functions available to the owner. The owner can perform actions including stock registration, registry management, pausing, and eligible rescue operations. A multisignature ownership structure is recommended before mainnet deployment. ### No Third Party Audit The contracts have undergone an internal security review. Both Medium findings identified during that review were fixed in the deployed bytecode. However, an independent third party audit has not yet been completed. The current security status should therefore not be represented as independently audited. ### Immutable Contracts The production contracts are not upgradeable. This removes an administrative upgrade path, but it also creates an operational limitation. If a defect requires changes to contract logic, the affected contract must be redeployed. Existing contract bytecode cannot be replaced through a proxy upgrade. ### Irreversible Peer Configuration The relationship between StoxVault and ConfidentialStock is configured through one time bindings. Once configured, these relationships cannot be changed. This prevents later redirection of the trust relationship. However, an incorrect configuration requires redeployment. Deployment procedures must therefore ensure that peer relationships are correct before they are finalized. ### Underlying Token Assumptions The StoxFi accounting model assumes supported underlying assets behave as standard ERC 20 tokens. StoxVault rejects fee on transfer behavior by checking the exact quantity received. However, rebasing behavior would break the collateral invariant. Supported assets must therefore be evaluated for compatibility with the StoxFi accounting model before integration. ### Confidential Supply Limit Confidential balances use `euint64`. The maximum supported confidential value is: `2^64 − 1` At 6 decimals, this represents approximately `18.4` trillion whole confidential units. StoxFi applies supply checks to prevent encrypted arithmetic from exceeding this range. The finite range remains a property of the confidential asset model. ### Precision Limit ConfidentialStock uses 6 decimals. For an 18 decimal underlying asset, StoxFi uses a conversion rate of: `10^12` Amounts below `10^-6` of one underlying token cannot be represented as a confidential unit. Sub unit remainders are refunded during shielding. ### Privacy Is Not Anonymity StoxFi protects confidential balances and confidential transfer amounts. It does not hide participant addresses. A public observer can still see: 1. Sender and recipient addresses 2. Asset type 3. Shield amount 4. Unshield amount 5. Transaction timing 6. Transaction frequency 7. Gas activity 8. Total collateral for each asset StoxFi should therefore not be described as anonymous or untraceable. ### Timing Correlation Shield and unshield activity is public. The timing of confidential transfers is also visible. An observer can use these timestamps to attempt to correlate entry, confidential activity, and exit. The protocol does not eliminate timing based inference. ### Amount Correlation Shield and unshield amounts are public. Observers may compare these values when attempting to associate entry and exit activity. This risk is especially relevant when there is limited independent activity within a confidential asset. ### Address Reuse Repeated use of the same address remains visible. An observer can associate multiple interactions with the same account even when confidential balances and transfer amounts remain encrypted. StoxFi does not provide address unlinkability. ### Anonymity Set Size Confidentiality of amounts does not guarantee that economic activity cannot be inferred. When only a small number of users are active in a particular confidential asset, public entry and exit information may make relationships easier to infer. The strength of this form of practical ambiguity therefore depends partly on the amount of independent activity within each asset. ### Asset Visibility The confidential asset contract being used is public. An observer can determine whether an address is interacting with cNVDA, cTSLA, cNFLX, or another supported confidential representation. StoxFi hides confidential balances and transfer amounts. It does not hide the asset type. ### Browser Metadata The current browser application communicates directly with third party RPC services and the FHE relayer. These services may observe network level information and request context associated with user interactions. This metadata sits outside the confidentiality guarantees provided by encrypted onchain balances. ### Frontend Compromise Frontend compromise remains an open risk. A malicious or compromised frontend could affect how users construct or submit interactions. Authoritative protocol state remains onchain, but the current architecture does not remove the security risk associated with the user interface. ### Testnet Assets The current NVDA, TSLA, and NFLX assets are demonstration tokens deployed by StoxFi. They are not real tokenized equities. They do not represent real NVIDIA, Tesla, or Netflix equity exposure. The current testnet demonstration therefore proves protocol functionality rather than production custody of real equity positions. ### Mainnet Configuration Mainnet configuration has not yet been written for the current implementation. StoxFi contracts have also not been deployed on Ethereum mainnet or Robinhood Chain mainnet. Production activation therefore requires additional configuration and deployment work. ### Development Infrastructure The current implementation does not yet use version control. Continuous integration and continuous deployment are also not configured. These are development infrastructure limitations rather than protocol level limitations, but they remain part of the current implementation status. ### Regulatory Considerations Tokenized equities operate within a regulatory environment that may impose requirements beyond the smart contract architecture itself. Regulatory considerations therefore remain a production deployment risk for StoxFi. The current implementation does not establish a regulatory framework for deployment with real tokenized equities. ### Current Risk Boundary The principal current limitations can be summarized as follows: | Area | Current Limitation | | ------------------------- | ------------------------------------------------------------ | | Cross chain access | Required CCIP lanes use sender allowlisting | | Reverse mainnet messaging | Robinhood mainnet to Ethereum mainnet direction not verified | | External messaging | Dependent on CCIP | | Confidential computation | Dependent on FHE infrastructure | | Redemption decryption | Dependent on threshold KMS | | Administration | Current ownership uses one externally owned account | | Security review | Third party audit pending | | Contract changes | Immutable contracts require redeployment | | Peer configuration | Incorrect one time binding requires redeployment | | Underlying assets | Must satisfy token behavior assumptions | | Confidential value | Limited to `euint64` range | | Precision | Confidential representation uses 6 decimals | | Privacy | Amount confidentiality without participant anonymity | | Correlation | Timing, amount, and address patterns remain observable | | Frontend | Browser compromise remains an open risk | | Assets | Current stock tokens are demonstration assets | | Mainnet | StoxFi production contracts not yet deployed | | Development process | Version control and continuous integration not configured | ### Limitations Summary StoxFi currently demonstrates confidential settlement of tokenized asset positions on test networks. The protocol successfully protects confidential balances and transfer amounts, but it does not remove all information leakage or external trust assumptions. Addresses remain visible. Entry and exit amounts remain public. Timing and activity patterns remain observable. Cross chain settlement depends on CCIP. Confidential computation and redemption depend on the FHE infrastructure. Administration currently depends on a single owner key. Production deployment also requires additional operational preparation, mainnet configuration, sender authorization for the required CCIP lane, integration with real tokenized equities, and independent security review. These limitations define the current boundary between the demonstrated StoxFi implementation and a production deployment. --- # 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/limitations-and-risks.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.