fix(svm): across plus to solana #747
Conversation
Signed-off-by: Reinis Martinsons <[email protected]>
Signed-off-by: Reinis Martinsons <[email protected]>
Signed-off-by: Reinis Martinsons <[email protected]>
Signed-off-by: Reinis Martinsons <[email protected]>
Signed-off-by: Reinis Martinsons <[email protected]>
Signed-off-by: Reinis Martinsons <[email protected]>
Signed-off-by: Reinis Martinsons <[email protected]>
Signed-off-by: Reinis Martinsons <[email protected]>
Signed-off-by: Reinis Martinsons <[email protected]>
Signed-off-by: Reinis Martinsons <[email protected]>
Signed-off-by: Reinis Martinsons <[email protected]>
Signed-off-by: Reinis Martinsons <[email protected]>
Signed-off-by: Reinis Martinsons <[email protected]>
| @@ -123,6 +124,10 @@ pub fn fill_v3_relay( | |||
| // Emit the FilledV3Relay event | |||
| let message_clone = relay_data.message.clone(); // Clone the message before it is moved | |||
|
|
|||
| if message_clone.len() > 0 { | |||
There was a problem hiding this comment.
This is slightly different than in EVM where we also check if the recipient is program. On Solana that would not be possible as the recipient is handler PDA, not the handler program itself. But I'm not sure if there would be a real use case for arbitrary messages that are not to be invoked by the handler.
| } | ||
|
|
||
| #[derive(AnchorDeserialize)] | ||
| pub struct CompiledIx { |
There was a problem hiding this comment.
This resembles compiled instructions within a transaction message, except we don't use the compact-u16 encoding for the sake of code simplicity.
| // Transfer value amount from the relayer to the first account in the message accounts. | ||
| // Note that the depositor is responsible to make sure that after invoking the handler the recipient account will | ||
| // not hold any balance that is below its rent-exempt threshold, otherwise the fill would fail. | ||
| if message.value_amount > 0 { |
There was a problem hiding this comment.
This is mostly useful when invoked handler transaction requires account initialization payer (e.g. when creating ATAs)
| data, | ||
| }; | ||
|
|
||
| // TODO: consider if the message handler requires signed invocation. |
There was a problem hiding this comment.
This mostly depends on whether the handler needs to retain any privileges on behalf of the user. E.g. if the handler performs a swap and forwards swapped-in tokens to user's ATA then its not important. On the other hand, if the handler deposits funds in a money market that does not allow depositing on behalf of end user then the handler would need to retain rights to withdraw the funds where such call must be authenticated via spoke pool PDA that is derived from depositing user address and origin chain.
This introduces support for Across+ targeting Solana. Since Solana instructions require additional context on account keys and their permissions we require that messages targeting Solana adhere to common format to encapsulate this additional information.
This also adds multicall handler implementation that allows to execute multiple instructions resembling compiled instruction format.
Considering the current structure of
FilledV3Relayevent we get limited by inner instruction size bounds when handler message exceeds 472 bytes, which based on tests allows up to 5 distributions to different recipients within the handler. This could be increased approx 1.6x if we were to emit the hashed version of the message before hitting outer transaction size limits. This could then be further increased if we were loading instruction parameters via buffer account for fills, like we do for executing relayer refunds.At current implementation the Spoke would invoke the handler without signatures, assuming the handler does not need to retain any privileges on behalf of end users (e.g. swapping out to user controlled ATA). If however the handler needs to retain user privileges (e.g. withdrawing from money market) we would need to introduce signed handler invocations where PDA seeds are derived from some combination of depositor address and origin chain.