Execution & Lifecycle

We've describe the URL scheme, as well as the GET and POST APIs. Let's now describe the full Action execution flow, which follows a typical HTTP REST API lifecycle:

• The client makes a GET request to the Action URL.

• The Action API returns a GET response body of human-readable metadata describing the actions at this URL, according to the specification above.

• The end-user chooses an action to take from the options available, and the client makes a POST request to the server at the specified URL, either the same as the GET URL, or different.

• The Action Provider receives this request, constructs a transaction (or soon message) that constitutes the action to be taken by the end-user, and returns a POST response body containing this transaction.

• The client takes this transaction and prepares it for the end-user to sign by sending it to a client-side wallet such as a chrome extension or embedded wallet.

• The user signs the transaction (or soon message), and the client handles submission of this transaction to the blockchain.

Validation

Actions providers support validation. GET and POST requests may first validate whether the action is able to be taken, and may customize their response metadata, and use disabled if validation fails.

For example, GET requests for a NFT that is up for auction may return an error message “This auction has completed” and render the “Bid” button as disabled . Or a GET request for a vote for a DAO governance proposal whose voting window has closed may return the error message “This proposal is no longer up for a vote” and the Vote yes & Vote no buttons as “disabled”.

Execution

Once signed, transactions are submitted to the blockchain, and the client is responsible for tracking the execution lifecycle.

Persistence

Actions do not persist their execution state beyond a single session. If a user refreshes the client, or leaves and comes back at a later time, past or current interactions with the Action are no longer reflected by the client.