Staging batch 2

cartesi-rollups_versioned_docs/version-2.0/api-reference/backend/exception.md

@@ -11,7 +11,7 @@ When an exception occurs during request processing, the dApp backend should:
 3. Exit the processing loop
 
 The Rollup HTTP Server will:
-- Skip the input with the reason [`EXCEPTION`](../graphql/enums/completion-status.md)
+- Skip the input with the reason [`EXCEPTION`](../jsonrpc/types.md#inputcompletionstatus)
 - Forward the exception message
 - Return status code 200
 

cartesi-rollups_versioned_docs/version-2.0/api-reference/backend/introduction.md

@@ -3,16 +3,18 @@ id: introduction
 title: Introduction
 ---
 
-The backend of a Cartesi dApp processes requests in the following manner:
+The backend of a Cartesi dApp retrieves a new request as follows:
 
-  - **Finish** — Called via [`/finish`](./finish.md), indicates that any previous processing has been completed and the backend is ready to handle the next request. The subsequent request is returned as the call's response and can be of the following types:
+- Finish — Communicates that any previous processing has been completed and that the backend is ready to handle the subsequent request. This following request is returned as the call's response and can be of the following types:
 
-    - **Advance** — Provides input to be processed by the backend to advance the Cartesi Machine state. When processing an Advance request, the backend can call the [`/voucher`](./vouchers.md), [`/delegate-call-voucher`](./delegate-call-vouchers.md), [`/notice`](./notices.md), and [`/report`](./reports.md) endpoints. For such requests, the input data contains both the payload and metadata, including the account address that submitted the input.
+  - **Advance** — Provides input to be processed by the backend to advance the Cartesi Machine state. When processing an `Advance` request, the backend can call the methods `/voucher`, `/notice`, and `/report`. For such requests, the input data contains the payload and metadata, such as the account address that submitted the input.
 
-    - **Inspect** — Submits a query about the application's current state. When running inside a Cartesi Machine, this operation is guaranteed to leave the state unchanged, as the machine reverts to its exact previous condition after processing. For Inspect requests, the input data contains only a payload, and the backend can only call the [`/report`](./reports.md) endpoint.
+  - **Inspect** — This function submits a query about the application's current state. When running inside a Cartesi Machine, this operation is guaranteed to leave the state unchanged since the machine is reverted to its exact previous condition after processing. For Inspect requests, the input data has only a payload.
+
+  :::caution Inspect requests
+  Inspect requests are best suited for non-production use, such as debugging and testing. They may not function reliably in production environments, potentially leading to errors or disruptions.
+  :::
 
-  - **Exception** — Called by the backend when it encounters an unrecoverable error during request processing. This signals to the Rollup HTTP Server that the current request processing failed and should be terminated. See [`/exception`](./exception.md) for more details.
-
 ## Advance and Inspect
 
 Here is a simple boilerplate application that handles Advance and Inspect requests:
@@ -120,34 +122,31 @@ while True:
 
 </Tabs>
 
-An **Advance** request involves sending input data to the base layer via JSON-RPC, allowing it to reach the dApp backend to change the application's state.
+An **Advance** request involves sending input data to the base layer via JSON-RPC so they can reach the dApp backend to change the application's state.
 
 ![img](../../../../static/img/v1.3/advance.jpg)
 
-Here is how an advance request works in the dApp architecture:
+In the dApp architecture, here is how an advance request plays out.
 
 - Step 1: Send an input to the [`addInput(address, bytes)`](../contracts/input-box.md#addinput) function of the InputBox smart contract.
 
-- Step 2: The HTTP Rollups Server reads the data and sends it to the Cartesi Machine for processing.
+- Step 2: The HTTP Rollups Server reads the data and gives it to the Cartesi machine for processing.
 
-- Step 3: After computation, the machine state is updated, and the results are returned to the rollup server.
+- Step 3: After the computation, the machine state is updated, and the results are returned to the rollup server.
 
-An **Inspect** request involves making an external HTTP API call to the rollups server to read the dApp state without modifying it.
+An **Inspect** request involves making an external HTTP API call to the rollups server to read the dApp state without changing it.
 
 ![img](../../../../static/img/v1.3/inspect.jpg)
 
 You can make a simple inspect call from your frontend client to retrieve reports.
 
-To perform an Inspect call, send an HTTP POST request to `<address of the node>/inspect/<application name>` with a payload in the request body. For example:
+To perform an Inspect call, use an HTTP GET request to `<address of the node>/inspect/<request path>`. For example:
 
 ```shell
-curl -X POST http://localhost:8080/inspect/<application name> \
-    -H "Content-Type: application/json" \
-    -d '{"payload": "0xdeadbeef"}'
+curl http://localhost:8080/inspect/mypath
 ```
 
-The payload should be a hex-encoded string starting with '0x' followed by pairs of hexadecimal numbers.
+Once the call's response is received, the payload is extracted from the response data, allowing the backend code to examine it and produce outputs as **reports**.
 
-After receiving the call's response, the payload is extracted from the response data, allowing the backend code to examine it and produce outputs as **reports**.
 
-The direct output types for **Advance** requests are [vouchers](./vouchers.md), [DELEGATECALL vouchers](./delegate-call-vouchers.md), [notices](./notices.md), and [reports](./reports.md), while **Inspect** requests generate only [reports](./reports.md).
+The direct output types for **Advance** requests are [vouchers](./vouchers.md), [notices](./notices.md), and [reports](./reports.md), while **Inspect** requests generate only [reports](./reports.md).

cartesi-rollups_versioned_docs/version-2.0/api-reference/backend/notices.md

@@ -13,7 +13,7 @@ Crucially, the base layer conducts on-chain validation of these notices through
 
 This validation process ensures the integrity and authenticity of the submitted notices, enabling the blockchain to verify and authenticate the declared off-chain events or conditions.
 
-Let's see how a Cartesi dApp's **Advance** request sends an output to the rollup server as a notice:
+Here are sample functions you can add to your application, then call to send a notice to the rollup server:
 
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
@@ -23,25 +23,30 @@ import TabItem from '@theme/TabItem';
 <pre><code>
 
 ```javascript
-async function handle_advance(data) {
-  console.log("Received advance request data " + JSON.stringify(data));
-
-  const inputPayload = data["payload"];
+import { stringToHex, hexToString } from "viem";
 
+const emitNotice = async (inputPayload) => {
+  let hexPayload = stringToHex(inputPayload); // convert payload from string to hex 
   try {
     await fetch(rollup_server + "/notice", {
       method: "POST",
       headers: {
         "Content-Type": "application/json",
       },
-      body: JSON.stringify({ payload: inputPayload }),
+      body: JSON.stringify({ payload: hexPayload }),
     });
   } catch (error) {
     // Handle error here
   }
+}
 
+async function handle_advance(data) {
+  console.log("Received advance request data " + JSON.stringify(data));
+  const payload = hexToString(data.payload); // convert input from hex to string for processing
+  await emitNotice(payload);
   return "accept";
 }
+
 ```
 
 </code></pre>
@@ -51,22 +56,16 @@ async function handle_advance(data) {
 <pre><code>
 
 ```python
-def handle_advance(data):
-   logger.info(f"Received advance request data {data}")
-
-   status = "accept"
-   try:
-       inputPayload = data["payload"]
-       # Send the input payload as a notice
-       response = requests.post(
-           rollup_server + "/notice", json={"payload": inputPayload}
-       )
-       logger.info(
-           f"Received notice status {response.status_code} body {response.content}"
-       )
-   except Exception as e:
-       # Emit report with error message here
-   return status
+# Notice creation Process from a message string
+def emit_notice(message):
+    notice_payload = {"payload": "0x" + message.encode("utf-8").hex()}
+    response = requests.post(rollup_server + "/notice", json=notice_payload)
+    if response.status_code == 200 or response.status_code == 201:
+        logger.info(f"Notice emitted successfully with data: {notice_payload}")
+    else:
+        logger.error(f"Failed to emit Notice with data: {notice_payload}. Status code: {response.status_code}")
+
+emit_notice("hello world")
 ```
 
 </code></pre>
@@ -75,5 +74,5 @@ def handle_advance(data):
 </Tabs>
 
 :::note querying notices
-Frontend clients can query notices using a GraphQL API exposed by Cartesi Nodes. [Refer to the documentation here](../../development/query-outputs.md/#query-all-reports) to query notices from the rollup server.
+Frontend clients can query notices using a GraphQL API exposed by the Cartesi Nodes. [Refer to the documentation here](../../development/query-outputs.md/#query-all-reports) to query notices from the rollup server.
 :::

cartesi-rollups_versioned_docs/version-2.0/api-reference/backend/vouchers.md

@@ -6,31 +6,27 @@ title: Vouchers
 
 Vouchers serve as a mechanism for facilitating on-chain actions initiated in the execution layer.
 
-Imagine vouchers as digital authorization tickets that grant dApps the authority to execute specific actions directly on the base layer. These vouchers encapsulate the details of the desired on-chain action, such as a token swap request or asset transfer.
+Imagine vouchers as digital authorization tickets, granting dApps the authority to execute specific actions directly on the base layer. This voucher encapsulates the details of the desired on-chain action, such as a token swap request or asset transfer.
 
-A voucher explicitly specifies the action that the dApp intends to execute on the base layer.
+The voucher explicitly specifies the action that the dApp intends to execute on the base layer.
 
 For instance, in a DeFi application built on Cartesi, users may want to swap one token for another. The dApp generates a voucher that authorizes the on-chain smart contract to execute the swap on the user's behalf.
 
-The [`Application`](../contracts/application.md) contract is crucial in validating and executing the received voucher on the blockchain. This execution process occurs through the [`executeOutput()`](../../contracts/application/#executeoutput) function, which handles different types of outputs including vouchers and DELEGATECALL vouchers.
+The [`CartesiDApp`](../contracts/application.md) contract is crucial in validating and executing the received voucher on the blockchain. This execution process occurs through the [`executeVoucher()`](../contracts/application.md/#executevoucher) function, ensuring that the action specified in the voucher is legitimate and authorized.
 
 The result of the voucher execution is recorded on the base layer. This recording typically involves submitting claims by a consensus contract, ensuring the integrity and transparency of the executed on-chain action.
 
 :::note create a voucher
 [Refer to the documentation here](../../development/asset-handling.md) for asset handling and creating vouchers in your dApp.
 :::
 
-## DELEGATECALL Vouchers
-
-Delegate call vouchers enable advanced smart contract interactions through the [DELEGATECALL](https://www.evm.codes/?fork=cancun#f4) opcode, allowing dApps to separate their execution logic from their storage context. For more details, see [DELEGATECALL Vouchers](./delegate-call-vouchers.md).
-
-## Epoch Configuration
+## Epoch configuration
 
 An epoch refers to a specific period during which a batch of updates is processed off-chain, and upon agreement by validators, the finalized state is recorded on-chain.
 
 Epoch Length is the number of blocks that make up an epoch. It determines how long each epoch lasts in terms of block counts. For instance, if an epoch length is set to 7200 blocks, the epoch will end once 7200 blocks have been processed. This length directly influences how frequently updates are finalized and recorded on the blockchain.
 
-One common use of vouchers in Cartesi dApps is to withdraw assets. Users initiate asset withdrawals by generating vouchers, which are then executed on the blockchain upon the closure of the corresponding epoch.
+One everyday use of vouchers in Cartesi dApps is to withdraw assets. Users initiate asset withdrawals by generating vouchers, which are then executed on the blockchain upon the closure of the corresponding epoch.
 
 You can manually set the epoch length to facilitate quicker asset deposits and withdrawals.