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: src/content/tutorial/6-gasless-transfers/4-static-relay/content.md
+36-20Lines changed: 36 additions & 20 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -32,6 +32,13 @@ Key roles involved:
32
32
-**Transfer contract** executes the token move and fee payment.
33
33
-**RelayHub** validates and routes meta-transactions across the network.
34
34
35
+
If you have never met OpenGSN before, keep this component cheat sheet handy:
36
+
37
+
-**Forwarder:** verifies the meta-transaction signature and keeps per-sender nonces so relays cannot replay old requests. The Nimiq transfer contract bundles a forwarder implementation; see the reference in the [Nimiq Developer Center](https://developers.nimiq.com/).
38
+
-**Paymaster:** refunds the relay in tokens such as USDT or USDC. For this tutorial the same transfer contract doubles as paymaster.
39
+
-**RelayHub:** the canonical on-chain registry of relays. Its API is documented in the [OpenGSN Docs](https://docs.opengsn.org/).
40
+
-**Relay server:** an off-chain service that watches the hub and exposes `/getaddr` plus `/relay` endpoints. Polygon’s networking requirements for relays are outlined in the [Polygon developer documentation](https://docs.polygon.technology/).
41
+
35
42
---
36
43
37
44
## Guardrails for This Lesson
@@ -50,7 +57,7 @@ Later lessons will replace each shortcut with production logic.
50
57
51
58
Create or update your `.env` file with the following values:
The sponsor wallet is the account that will sign messages and reimburse the relay.
92
+
The concrete contract addresses are published in `@cashlink/currency`’s constants module and mirrored in the [Nimiq wallet gasless guide](https://developers.nimiq.com/). Always verify them against the latest deployment notes before running on mainnet.
85
93
86
94
---
87
95
88
96
## Step 3: Retrieve the USDT Nonce and Approval Amount
89
97
90
-
USDT uses its own permit-style approval. Fetch the current nonce and compute how much the transfer contract is allowed to spend (transfer amount + relay fee).
98
+
USDT on Polygon does _not_ implement the standard ERC‑2612 permit. Instead it exposes `executeMetaTransaction`, which expects you to sign the encoded `approve` call. The `nonces` counter you query below is USDT’s own meta-transaction nonce (documented in [Tether’s contract implementation](https://docs.opengsn.org/contracts/erc-2771.html)), so we can safely reuse it when we sign the approval.
99
+
100
+
Fetch the current nonce and compute how much the transfer contract is allowed to spend (transfer amount + relay fee).
USDT on Polygon uses `executeMetaTransaction` for gasless approvals. Build the EIP-712 MetaTransaction payload and sign it.
119
+
USDT on Polygon uses `executeMetaTransaction` for gasless approvals. Build the EIP‑712 MetaTransaction payload and sign it. Notice the domain uses the `salt` field instead of `chainId`; that is specific to the USDT contract. Compare this to the generic permit flow covered in [OpenGSN’s meta-transaction docs](https://docs.opengsn.org/gsn-provider/metatx.html) to see the differences.
The relay expects a second EIP-712 signature covering the meta-transaction wrapper. Gather the contract nonce and sign the payload.
186
+
The relay expects a second EIP‑712 signature covering the meta-transaction wrapper. This time the domain is the **forwarder** (embedded inside the transfer contract). Gather the contract nonce and sign the payload.
Use the OpenGSN HTTP client to send the request to your chosen relay.
225
+
Use the OpenGSN HTTP client to send the request to your chosen relay. The worker nonce check prevents you from handing the relay a `relayMaxNonce` that is already stale—if the worker broadcasts several transactions in quick succession, your request will still slide in. Likewise, `validUntil` in the previous step protects the relay from signing requests that could be replayed months later.
- ✅ Understood the flow between approval, relay request, and paymaster contract.
264
280
- ✅ Prepared the foundation for relay discovery and fee optimization.
265
281
266
-
Continue to**Lesson 4**to discover relays dynamically via RelayHub events.
282
+
Next up,**Lesson 5**walks through discovering relays dynamically from the RelayHub and filtering them with health checks informed by the [OpenGSN relay operator guide](https://docs.opengsn.org/relay/). That will let you replace today’s hardcoded URL with resilient discovery logic.
`AbortController` gives us a portable timeout without extra dependencies, which keeps the sample compatible with both Node.js scripts and browser bundlers.
126
+
95
127
Checks to keep in mind:
96
128
97
129
- **Version** must start with 2.x to match the OpenGSN v2 protocol.
98
130
- **Network ID** should be 137 for Polygon mainnet.
99
131
- **Worker balance** needs enough POL to front your transaction (the example uses 0.01 POL as a floor).
100
-
-**Recent activity** ensures the worker is still alive and signing transactions.
132
+
- **Readiness flag** confirms the relay advertises itself as accepting requests.
133
+
- **Fee caps** ensure you never accept a base fee or a percentage beyond your policy.
101
134
102
135
---
103
136
104
137
## Step 3: Select the First Healthy Relay
105
138
106
139
Iterate through the registrations until you find one that passes validation. You can collect alternates for fallback if desired.
0 commit comments