-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sending EIP-712 Transactions #171
Comments
I like this flexibility; EIP-712 could be a great suggestion. |
Signing a EIP-712 structure, and sending a transaction are two independent actions. |
Just as an analogy, take a look at cast wallet sign. |
In our case, we are considering executing the full process:
The nonce is important for us... |
Are you talking about espresso sequencer? Please provide context in the original post. |
/nonce and /submit Yes, for Espresso and Paio + Avail |
Does espresso and paio + avail follow the exact same |
Yes the same API |
Probably something like |
Something like aws cli |
Today we have:
Could be:
|
Currently every type of input is a subcommand of Consider also the future adoption of
Even though coprocessor might be a different case, because the user develops a custom smart contract, which then sends an input to the coprocessor task issuer. We don't want to replicate what Coming back to "L2" inputs, it's not very clear to me if sending a transaction to espresso or paio is equivalent to the current structure of the It looks more to me like sending a generic input, and then choosing the destination, which is either the InputBox L1 contract, or a sequencer. |
I agree, how about:
|
How about:
|
Nice! |
For the client side, it does not matter whether it is Espresso or Paio, as the /submit endpoint receives the same payload. How about: |
I wrote a draft following the |
You would have to ask for the address to send |
The command line already asks for the address... |
Well, in case of sequencer !== evm, the address should not default to anvil, as you are not sending to anvil, but to the sequencer. Not there is also a chain-id parameter. |
Hi folks. I think there is some confusion here. The user is not sending the input to a specific sequencer. He doesn't need to care if this will go to Espresso or Paio, only that the input will be submitted to an L2 endpoint that may act as a gateway to forward it to wherever is appropriate (usually some sequencer like Espresso or Paio). I'd use one of these options:
For (1), I admit I'm not very fond of "type", which is too abstract. Maybe something like "layer", "network", "destination" or something like that could work better. But atm I think I still prefer "type" over those :P |
As a curiosity, which may be related: is there a |
Thinking more about this, I'm leaning more towards |
There is no send for ERC-4337 operations. From the application backend perspective there is no difference of a generic input that comes from ERC-4337 (other than the fact that the sender is a smart account). I think the utility of the |
I haven't seen the term "format" in this context, but I have seen the term "type", as in transaction types (for ethereum). But ERC-4337 and these paio thing are not transactions. Sometimes they are called meta-transactions, and ERC-4337 call them UserOps. |
Hey everyone,
We’re considering how to structure a command for sending EIP-712 transactions and would love some input.
The process includes:
/nonce
endpoint)./submit
endpoint).This applies to both Espresso and Paio + Avail, which follow the same API structure.
Possible Approaches:
cartesi send
A general send command with an option to specify EIP-712 format.cartesi <context> send
A subcommand that provides additional context before sending, such ascartesi l2 send
.The text was updated successfully, but these errors were encountered: