You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A client calls the [transfer_lock] or [transfer_burn] instruction based on whether the program is in "locking" or "burning" mode. The program mode is set during initialization. When transferring, the client must specify the amount of the transfer, the recipient chain, the recipient address on the recipient chain, and the boolean flag `should_queue` to specify whether the transfer should be queued if it hits the outbound rate limit.
73
+
74
+
> Using the wrong transfer instruction, i.e. [`transfer_lock`] for a program that is in "burning" mode, will result in `InvalidMode` error.
75
+
76
+
Depending on the mode and instruction, the following will be produced in the program logs:
77
+
78
+
```
79
+
Program log: Instruction: TransferLock
80
+
Program log: Instruction: TransferBurn
81
+
```
82
+
83
+
Outbound transfers are always added into an Outbox via the `insert_into_outbox` method. This method checks the transfer against the configured outbound rate limit amount to determine whether the transfer should be rate limited. The Outbox is a Solana Account which holds details of the outbound transfer. If no rate limit is hit, the transfer can be released from the Outbox immediately. If a rate limit is hit, the transfer can only be released from the Outbox after the rate limit delay duration has expired.
84
+
85
+
2. Rate Limiting
86
+
87
+
The program checks rate limits via the `consume_or_delay` function during the transfer process. The Solana rate limiting logic is equivalent to the EVM rate limiting logic:
88
+
89
+
If the transfer amount fits within the current capacity:
90
+
91
+
- Reduce the current capacity
92
+
- Refill the inbound capacity for the destination chain
93
+
- Add the transfer to the outbox with `release_timestamp` set to the current timestamp, so it can be released immediately.
94
+
95
+
If the transfer amount does not fit within the current capacity:
96
+
97
+
- If `shouldQueue = true`, add the transfer to the outbox with `release_timestamp` set to the current timestamp plus the configured `RATE_LIMIT_DURATION`.
98
+
- If `shouldQueue = false`, revert with a `TransferExceedsRateLimit` error
99
+
100
+
3. Transmit
101
+
102
+
The caller then needs to request each Transceiver to send messages via the [`release_outbound`] instruction. To execute this instruction, the caller needs to pass the account of the Outbox item to be released. The instruction will then verify that the Transceiver is one of the specified senders for the message. Transceivers then send the messages based on the verification backend they are using.
103
+
104
+
For example, the Wormhole Transceiver will send by calling [`post_message`] on the Wormhole program, so that the Wormhole Guardians can observe and verify the message.
105
+
106
+
> When `revert_on_delay` is true, the transaction will revert if the release timestamp has not been reached. When `revert_on_delay` is false, the transaction succeeds, but the outbound release is not performed.
107
+
108
+
The following will be produced in the program logs:
109
+
110
+
```
111
+
Program log: Instruction: ReleaseOutbound
112
+
```
113
+
114
+
4. Receive
115
+
116
+
Similar to EVM, Transceivers vary in how they receive messages, since message relaying and verification methods may differ between implementations.
117
+
118
+
The Wormhole Transceiver receives a verified Wormhole message on Solana via the [`receive_message`] entrypoint instruction. Callers can use the [`receive_wormhole_message`] Anchor library function to execute this instruction. The instruction verifies the Wormhole VAA and stores it in a `VerifiedTransceiverMessage` account.
119
+
120
+
The following will be produced in the program logs:
121
+
122
+
```
123
+
Program log: Instruction: ReceiveMessage
124
+
```
125
+
126
+
[`redeem`] checks the inbound rate limit and places the message in an Inbox. Logic works the same as the outbound rate limit we mentioned previously.
127
+
128
+
The following will be produced in the program logs:
129
+
130
+
```
131
+
Program log: Instruction: Redeem
132
+
```
133
+
134
+
5. Mint or Unlock
135
+
136
+
The inbound transfer is released and the tokens are unlocked or minted to the recipient (depending on the mode) through either [`release_inbound_mint`] (if the mode is `burning`) or [`release_inbound_unlock`] (if the mode is `locking`). Similar to transfer, using the wrong transfer instruction, i.e. [`release_inbound_mint`] for a program that is in "locking" mode, will result in `InvalidMode` error.
137
+
138
+
> When `revert_on_delay` is true, the transaction will revert if the release timestamp has not been reached. When `revert_on_delay` is false, the transaction succeeds, but the minting/unlocking is not performed.
139
+
140
+
Depending on the mode and instruction, the following will be produced in the program logs:
0 commit comments