Sending EIP-712 Transactions

[fabiooshiro]

Hey everyone,

We’re considering how to structure a command for sending EIP-712 transactions and would love some input.

The process includes:

1. Retrieving the nonce (/nonce endpoint).
2. Building the EIP-712 message.
3. Signing the transaction.
4. Submitting the transaction (/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 as cartesi l2 send.
• Other suggestions?

[sandhilt]

I like this flexibility; EIP-712 could be a great suggestion.

[tuler]

Signing a EIP-712 structure, and sending a transaction are two independent actions.
It doesn't mean a send subcommand can exist for sending a different transaction, but the destination is more relevant for the subcommand context than the EIP-712 building and signing process.

[tuler]

Just as an analogy, take a look at cast wallet sign.
It's under the wallet command. Not a send operation.

[fabiooshiro]

In our case, we are considering executing the full process:

1. Retrieve the nonce.
2. Build the EIP-712 message.
3. Sign the transaction.
4. Send the transaction to the /submit endpoint.

The nonce is important for us...

[tuler]

Are you talking about espresso sequencer? Please provide context in the original post.
What endpoint?

[fabiooshiro]

/nonce and /submit

Yes, for Espresso and Paio + Avail

[tuler]

/nonce and /submit

Yes, for Espresso and Paio + Avail

Does espresso and paio + avail follow the exact same /nonce and /submit API?

[fabiooshiro]

Yes the same API

[fabiooshiro]

Probably something like cartesi l2 send is the best option

[fabiooshiro]

Something like aws cli
aws <service> <commands>
aws s3 ls

[fabiooshiro]

Today we have:

cartesi send
? Select send sub-command
  Send DApp address input to the application.
  Send ERC-20 deposit to the application.
  Send ERC-721 deposit to the application.
  Send ether deposit to the application.
❯ Send generic input to the application.
Sends generics inputs to the application, optionally in interactive mode.

Could be:

cartesi send
? Select send sub-command
  Send DApp address input to the application.
  Send ERC-20 deposit to the application.
  Send ERC-721 deposit to the application.
  Send ether deposit to the application.
  Send generic input to the application.
❯ Send L2 input to the application.

[tuler]

Currently every type of input is a subcommand of cartesi send.
The cartesi send command itself is another command that interactively allows the selection of one of the subcommands.

Consider also the future adoption of cartesi coprocessor, and a possible impact, with two possibilities:

• move all rollups related inputs to cartesi rollups send [subcommand].
• or simply the addition of a new send subcommand for coprocessor.

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 cast already provides, and we probably better off just driving the user to use cast.

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 send subcommands. Because it looks to me more like a destination, not an input type or structure.

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.

[fabiooshiro]

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:

cartesi send
? Select send sub-command
  Send DApp address input to the application.
  Send ERC-20 deposit to the application.
  Send ERC-721 deposit to the application.
  Send ether deposit to the application.
  Send generic L1 input to the application.
❯ Send generic L2 input to the application.

[tuler]

How about:

cartesi send generic [--sequencer evm|espresso]