> 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/cross-chain-messaging-with-ccip.md).
# Cross Chain Messaging with CCIP
StoxFi uses Chainlink CCIP to coordinate activity between StoxVault on Robinhood Chain and ConfidentialStock on Ethereum.
CCIP is used for **arbitrary messaging**.
The underlying ERC 20 does not travel through CCIP and does not leave Robinhood Chain during the confidential lifecycle.
Instead, StoxFi sends instructions between the two environments.
A shield instruction authorizes the creation of a confidential balance on Ethereum.
A release instruction authorizes the return of underlying collateral on Robinhood Chain.
### Cross Chain Message Flow
**StoxFi CCIP Message Flow**
The underlying collateral remains in StoxVault while cross chain messages coordinate the creation and redemption of the confidential representation.
### Shield Direction
During shielding, StoxVault first receives and locks the underlying ERC 20.
Once the deposit has been validated and converted into confidential units, StoxVault creates a CCIP message for the corresponding ConfidentialStock contract.
The message data contains:
`recipient`
`uint64 amount`
The message does not contain token transfer instructions.
The CCIP `tokenAmounts` field remains empty.
The underlying asset therefore remains inside StoxVault while the message communicates how much confidential value should be created on Ethereum.
### Mint Instruction
StoxVault sends the message through the CCIP Router on Robinhood Chain.
The message is configured with a gas limit for execution on the destination chain.
The current mint gas limit is:
`1,500,000`
StoxFi permits out of order execution for these messages.
CCIP fees can be paid using LINK or the native token.
Once the message reaches Ethereum, it is delivered through the destination CCIP Router to ConfidentialStock.
ConfidentialStock validates the message before creating the encrypted balance.
### Release Direction
The reverse message begins after a redemption has been successfully finalized.
At this stage, the confidential amount has already been burned and its public decryption proof has been verified.
ConfidentialStock creates a release instruction containing:
`destination`
`uint64 amount`
The release message is sent through the Ethereum CCIP Router toward Robinhood Chain.
The current release gas limit is:
`400,000`
Once delivered, StoxVault validates the message and releases the corresponding underlying ERC 20.
### Message Validation
Cross chain messages can authorize the creation of confidential value or the release of underlying collateral.
For this reason, StoxFi does not accept arbitrary inbound messages.
Each receiving contract validates four properties.
#### 1. Router
The message must arrive through the configured CCIP Router.
#### 2. Source Chain
The message must originate from the expected source chain.
#### 3. Sender
The message sender must match the bound StoxFi peer on the source chain.
For StoxVault, the expected peer is the corresponding ConfidentialStock.
For ConfidentialStock, the expected peer is the bound StoxVault.
#### 4. Replay Protection
Each processed CCIP message identifier is recorded.
If the same message is presented again, it cannot be processed a second time.
This prevents a previously valid mint or release instruction from being replayed.
### Peer Binding
The relationship between StoxVault and ConfidentialStock is explicitly configured.
StoxVault maintains the confidential peer associated with each supported stock.
ConfidentialStock maintains its bound vault.
These relationships are configured once.
They cannot be repointed after configuration.
A wiring mistake therefore requires redeployment rather than changing the existing trust relationship.
### Messages, Not Assets
The distinction between messaging and asset movement is central to the StoxFi architecture.
During shielding:
**The underlying token moves from the user into StoxVault.**
It does not move to Ethereum.
During confidential settlement:
**The collateral remains in StoxVault.**
Only the confidential representation changes on Ethereum.
During unshielding:
**A release instruction travels back to Robinhood Chain.**
The underlying token then moves from StoxVault to the redemption destination.
CCIP therefore coordinates state between the two sides of StoxFi without acting as the custody location for the underlying stock.
### Message Contents
| Direction | Purpose | Message Data | Token Transfer |
| --------------------------- | ----------------------------- | ------------------------------- | -------------- |
| Robinhood Chain to Ethereum | Create confidential balance | Recipient and `uint64` amount | None |
| Ethereum to Robinhood Chain | Release underlying collateral | Destination and `uint64` amount | None |
The amounts carried in these messages are public.
This is consistent with the StoxFi confidentiality boundary.
Shield amounts are public before the confidential interval begins.
Redemption amounts are public when the confidential interval ends.
### Message Fees
CCIP message fees can be paid using either LINK or the native token.
The choice is supplied when initiating the relevant StoxFi operation.
The fee applies to the cross chain instruction rather than to movement of the underlying collateral because StoxFi does not use CCIP token transfer.
### Redemption Resumability
StoxFi does not implement a separate custom retry or recovery system for CCIP.
Instead, the redemption architecture is designed so that the critical confidential state transition occurs before the release instruction.
The encrypted redemption amount is burned when the redemption request is created.
Finalization occurs separately after public decryption.
This separation allows a pending redemption to be resumed without making the burned confidential value spendable again.
Redemption finalization is also permissionless.
Another account can submit the required finalization transaction, but the redemption destination cannot be changed.
### Current Testnet Configuration
StoxFi currently uses CCIP between Robinhood Chain testnet and Ethereum Sepolia.
#### Robinhood Chain Testnet
Chain selector:
`2032988798112970440`
CCIP Router:
`0x30D197C6F5bE050D5525dD94d01760FaCdB67e7C`
#### Ethereum Sepolia
Chain selector:
`16015286601757825753`
CCIP Router:
`0x0BF3dE8c5D3e8A2B34D2BEeB17ABfCeBaf363A59`
Both testnet directions currently operate with CCIP allowlisting enabled.
### Mainnet Constraint
The Ethereum mainnet to Robinhood mainnet CCIP lane exists, but its allowlist is enabled.
StoxFi therefore requires approval for its sender before that direction can be used for a mainnet deployment.
The reverse Robinhood mainnet to Ethereum mainnet lane has not been verified in the current implementation.
This CCIP access requirement is the current infrastructure constraint affecting mainnet activation.
It is not a limitation of StoxFi's encrypted balance architecture.
---
# 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/cross-chain-messaging-with-ccip.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.
