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
Copy file name to clipboardExpand all lines: docs/NttManager.md
+17-6Lines changed: 17 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,13 +17,24 @@ uint16 payload_len // length of the payload
17
17
18
18
### Payloads
19
19
20
+
> Note: Integrators who need to send different types of payloads should also use a unique 4-byte prefix to distinguish them from `NativeTokenTransfer` and one another.
21
+
20
22
#### NativeTokenTransfer
21
23
22
24
```go
23
-
[4]byte prefix = 0x994E5454// 0x99'N''T''T'
24
-
uint8 decimals // number of decimals for the amount
[32]byte recipient_address // the address of the recipient
30
+
uint16 recipient_chain // the Wormhole Chain ID of the recipient
31
+
```
32
+
33
+
To support integrators who may want to send additional, custom data with their transfers, this format may be extended to also include these additional, optional fields. Customizing transfers in this way ensures compatibility of the canonical portion of the payload across the ecosystem (Connect, explorers, NTT Global Accountant, etc).
34
+
35
+
In order to aid parsers in identifying your additional payload, it is recommended to start it with a unique 4-byte prefix.
36
+
37
+
```go
38
+
uint16 additional_payload_len // length of the custom payload
39
+
[]byte additional_payload // custom payload - recommended that the first 4 bytes are a unique prefix
Copy file name to clipboardExpand all lines: evm/README.md
+37-7Lines changed: 37 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,6 @@
1
-
# Message Lifecycle (EVM)
1
+
# EVM
2
+
3
+
## Message Lifecycle (EVM)
2
4
3
5
1.**Transfer**
4
6
@@ -205,9 +207,37 @@ $ anvil --help
205
207
$ cast --help
206
208
```
207
209
208
-
### Deploy Wormhole NTT
210
+
## Message Customization
211
+
212
+
See the [NttManager](../docs/NttManager.md) doc for wire format details.
213
+
214
+
> Note: The size of `NttManager` is significantly higher (and very close to the contract size limit) than `NttManagerNoRateLimiting`. See [No-Rate-Limiting](#no-rate-limiting) for more detail.
215
+
216
+
### NativeTokenTransfer Additional Payload
217
+
218
+
Your contract can extend `NttManagerNoRateLimiting` to provide an additional payload on the `NativeTokenTransfer` message. Override the following:
219
+
220
+
-`_prepareNativeTokenTransfer`
221
+
-`_handleAdditionalPayload`
222
+
223
+
Be sure to review the code to ensure that they are called at an appropriate place in the flow for your use case.
224
+
225
+
> Note: This is _not_ supported when RateLimiting is enabled, as this implementation does not propagate the additional payloads on queued messages. Use either with `NttManager` when `_rateLimitDuration` is set to `0` and `_skipRateLimiting` is set to `true` in the constructor or with `NttManagerNoRateLimiting`.
226
+
227
+
### Custom Manager Payloads
228
+
229
+
`NttManager` (or `NttManagerNoRateLimiting`) can also be extended to exchange other kinds of custom messages. To send custom messages, create a new public function and roughly follow the steps in `_transfer`. What exactly you need to do will vary on your use case, but in order to leverage the existing transceivers, you will roughly need to
230
+
231
+
- call `_prepareForTransfer`
232
+
- construct and encode your payload
233
+
- construct the `NttManagerMessage` payload
234
+
- call `_sendMessageToTransceivers`
235
+
236
+
On the receiving side, override `_handleMsg` and adjust its code based on your custom payload prefixes, defaulting to `_handleTransfer`.
237
+
238
+
## Deploy Wormhole NTT
209
239
210
-
####Environment Setup
240
+
### Environment Setup
211
241
212
242
Note: **All Chain IDs set in the deployment environment files and configuration files should be the Wormhole Chain ID**
213
243
@@ -222,7 +252,7 @@ Do this for each blockchain network that the `NTTManager` and `WormholeTransceiv
222
252
223
253
Currently the `MAX_OUTBOUND_LIMIT` is set to zero in the sample `.env` file. This means that all outbound transfers will be queued by the rate limiter.
224
254
225
-
####Config Setup
255
+
### Config Setup
226
256
227
257
Before deploying the contracts, navigate to the `evm/cfg` directory and copy the sample file. Make sure to preserve the existing name:
228
258
@@ -242,7 +272,7 @@ Configure each network to your liking (including adding/removing networks). We w
242
272
243
273
Currently the per-chain `inBoundLimit` is set to zero by default. This means all inbound transfers will be queued by the rate limiter. Set this value accordingly.
244
274
245
-
####Deploy
275
+
### Deploy
246
276
247
277
Deploy the `NttManager` and `WormholeTransceiver` contracts by running the following command for each target network:
Tokens powered by NTT in **burn** mode require the `burn` method to be present. This method is not present in the standard ERC20 interface, but is found in the `ERC20Burnable` interface.
0 commit comments