feat: Update docs on Solana Ccm fallback mechanism #413
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
| - The receiver program on the destination chain must implement the [described interface](#receive-call-and-asset-on-the-receiver-program). | ||
| - If the amount of gas provided is not enough to cover the costs of the receiver's logic on the destination chain, the transaction will revert on-chain. An example of a compute unit estimation is provided [below](#compute-budget-estimation). | ||
| - In the event of a transaction reverting due to insufficient gas the nonce will be consumed making the transaction invalid. | ||
|
|
||
|
|
||
| <Callout type="warning"> | ||
|
|
||
| While Chainflip will do it's best to succesfully execute any swap with cross-chain messaging, CCM transactions that revert on Solana will currently result in funds not being egressed. Ensure the transaction doesn't revert due to lack of compute units or due to the receiver's logic. | ||
| While Chainflip will do its best to successfully execute any swap with cross-chain messaging, CCM transactions that revert on Solana will currently result in funds not being egressed. Ensure the transaction doesn't revert due to a lack of "compute units" or the receiver's logic. |
There was a problem hiding this comment.
I think that now that there is the fallback mechanism we don't need to flag this as a warning, we could put it as part of the Solana Considerations.
pages/swapping/integrations/advanced/cross-chain-messaging/sol-ccm.mdx
Outdated
Show resolved
Hide resolved
| pub struct CcmAddress { | ||
| pub pubkey: Pubkey, | ||
| pub is_writable: bool, | ||
| } | ||
|
|
||
| pub struct CcmAccounts { | ||
| pub cf_receiver: CcmAddress, | ||
| pub remaining_accounts: Vec<CcmAddress>, | ||
| pub fallback_address: Pubkey, | ||
| } |
There was a problem hiding this comment.
I think it would be more accessible and precise if, in the docs, we used primitive types instead of our own internal type definitions, so something like:
cf_receiver: { pubkey: [u8; 32], is_writable: u8 }
remaining_accounts: Array<{ pubkey: [u8; 32], is_writable: u8 }>
fallback_address: [u8; 32]
We could even provide the scale metadata?
Otherwise it's easy to assume that eg. the address is base58-encoded.
We could also link to some SCALE docs and common libraries, and provide some example code in eg. TS or Python, as we do elsewhere.
There was a problem hiding this comment.
That's totally true, especially relevant for the address encoding you mentioned.
Regarding the scale encoding library that makes sense but I would maybe do it also as part of extending the docs for Vault swaps as they will also need the same encoding, especially since I don't think anyone is on a rush to implement that.
There was a problem hiding this comment.
Yeah not saying all of the above has be part of this PR, but we should at least use non-custom types in the example.
Having said that, most integrators don't need to know this: they should be able to just request the encoding via an rpc, and then get back some encoded data that they just need to slot into the tx somewhere.
There was a problem hiding this comment.
Do we have such a RPC at the moment?
There was a problem hiding this comment.
I had the raw Rust code in there just for reference, in case someone wants to get "technical".
I've added the "encoded" type - I'm unsure if what I had in there makes sense.
Should we have more detailed instructions on how to get everything encoded? (either JS code with scale or the RPC call that do the encoding for the users)
There was a problem hiding this comment.
We don't have the rpc yet so it's good to document it. I think it looks good now, we can do the scale encoding when I expand the contract swaps.
|
As I understand this feature is in 1.7. Should we merge it anyway so any party that is looking into this has already the "final implementation" even though this won't work in main yet? @dandanlen |
Closes PRO-1719
Updated documentation about Solana Ccm's fallback mechanism.
Corresponding code change is here: chainflip-io/chainflip-backend#5316