Conversation
docs/design/FACILITATOR.md
Outdated
| - `maxFeeValue` **remains ETH-only**, paid via `msg.value` | ||
| - Claims replace pull payments: `claim(tokenAddress, payee)` is the generic, permissionless, asset-aware claim mechanism | ||
| - Pending claims are tracked by `(payee, tokenAddress)` | ||
| - Token allowlists (global + per-app) gate which tokens are accepted |
There was a problem hiding this comment.
There is only the global allowlist
| #### New function: `submitRequestFor` | ||
|
|
||
| ```solidity | ||
| function submitRequestFor( |
There was a problem hiding this comment.
Should submitRequestFor support also Deploy requests?
| An EIP-712 typed data signature over the request parameters, proving the user authorized this specific request: | ||
|
|
||
| ``` | ||
| RequestAuthorization { |
There was a problem hiding this comment.
Considering that the ecrecover can recover a valid address from a signature, given a wrong message, maybe it is safer to add the sender address inside the RequestAuthorization, so the contract can verify that the address from the ecrecover is the one expected.
There was a problem hiding this comment.
good observation: added
| │ nonces[user]++ | ||
| │ | ||
| ├─ 4. If assetAmount > 0: validate token allowlists | ||
| │ require(globalAllowedTokens[tokenAddress]) |
There was a problem hiding this comment.
I suppose it should reject the request if the tokenAddress is ETH, maybe it is better to be explicit
docs/design/FACILITATOR.md
Outdated
| │ | ||
| ├─ 4. If assetAmount > 0: validate token allowlists | ||
| │ require(globalAllowedTokens[tokenAddress]) | ||
| │ require(appAllowedTokens[applicationId][tokenAddress]) |
There was a problem hiding this comment.
appAllowedTokens doens't exist anymore
docs/design/FACILITATOR.md
Outdated
|
|
||
| #### Core Facilitation Endpoints | ||
|
|
||
| - **`POST /submit`** — Generic gasless submission. Accepts the user's EIP-712 request signature, EIP-3009 deposit signature (if `assetAmount > 0`), and request parameters. Calls `submitRequestFor()` on-chain. Works for any request type (`ASSOCIATEKEY`, `DEPOSIT`, `WITHDRAWAL`, `PROCESS`, etc.). |
There was a problem hiding this comment.
The only requestType supported are "ASSOCIATEKEY", "Process", "DEPLOY" and "Deanonymization"
docs/design/FACILITATOR.md
Outdated
|
|
||
| #### ASSOCIATEKEY | ||
|
|
||
| Works naturally with the facilitator: the user signs a request authorization with their key payload (133 bytes). The recovered address from the EIP-712 signature is the user whose key is being associated. No special handling needed. |
There was a problem hiding this comment.
the key payload is no more only 133 bytes (at least, not always)
|
|
||
| #### DEANONYMIZATION | ||
|
|
||
| Deanonymization will not be covered by the facilitator feature. |
There was a problem hiding this comment.
This means the facilitator would reject a DEANONYMIZATION request?
There was a problem hiding this comment.
yes, rejected
docs/design/FACILITATOR.md
Outdated
|
|
||
| ### 6.2. Signature Binding | ||
|
|
||
| The request authorization signs `payloadHash` (not the raw payload) to keep signature size manageable. The contract verifies `keccak256(payload) == payloadHash` to ensure the facilitator cannot alter the payload. |
There was a problem hiding this comment.
So payloadHash is one of the parameter of submitRequestFor?
There was a problem hiding this comment.
explained better in 6.2
docs/design/FACILITATOR.md
Outdated
|
|
||
| ### 4.1. Why EIP-3009 | ||
|
|
||
| EIP-3009 defines `transferWithAuthorization` — a standard that allows a token holder to authorize a transfer via off-chain signature. A third party (the facilitator) can then execute the transfer on-chain without the token holder spending gas. |
There was a problem hiding this comment.
In the ERC-3009 it is suggested to use receiveWithAuthorization instead of transferWithAuthorization for avoid front-running attack
2 participants
No description provided.