Refactor/rollups-apis

cartesi-rollups_versioned_docs/version-1.5/development/asset-handling.md

@@ -12,7 +12,7 @@ As with any execution layer solution, a Cartesi dApp that wants to manipulate as
 
 Currently, Cartesi Rollups support the following types of assets:
 
-- [Ether (ETH)](../rollups-apis/json-rpc/portals/)
+- [Ether (ETH)](../rollups-apis/json-rpc/portals/EtherPortal.md)
 - [ERC-20](../rollups-apis/json-rpc/portals/ERC20Portal.md)
 - [ERC-721](../rollups-apis/json-rpc/portals/ERC721Portal.md)
 - [ERC-1155 Single](../rollups-apis/json-rpc/portals/ERC1155SinglePortal.md)

cartesi-rollups_versioned_docs/version-2.0/core-concepts/architecture.md

@@ -48,28 +48,28 @@ The Cartesi Machine achieves its unique balance of scalability and security by p
 
 ## On-chain components
 
-The on-chain part of Cartesi Rollups consists of [several smart contracts](../rollups-apis/json-rpc/overview.md) deployed on the base layer. 
+The on-chain part of Cartesi Rollups consists of [several smart contracts](../api-reference/json-rpc/overview.md) deployed on the base layer. 
 
 Here is an overview of the major contracts, with each serving a specific role in the dApp ecosystem:
 
 ### InputBox
-The [InputBox](../rollups-apis/json-rpc/input-box.md) contract is the entry point for user interactions with the off-chain layer. All inputs destined for a Cartesi dApp are first submitted to this contract, which then emits events that the off-chain components can process.
+The [InputBox](../api-reference/json-rpc/input-box.md) contract is the entry point for user interactions with the off-chain layer. All inputs destined for a Cartesi dApp are first submitted to this contract, which then emits events that the off-chain components can process.
 
 ### CartesiDApp
-Each Cartesi dApp is associated with a unique instance of the [CartesiDApp](../rollups-apis/json-rpc/application.md) contract. This contract acts as the on-chain representation of the dApp and can hold ownership of digital assets on the base layer, including Ether, ERC-20 tokens, and NFTs.
+Each Cartesi dApp is associated with a unique instance of the [CartesiDApp](../api-reference/json-rpc/application.md) contract. This contract acts as the on-chain representation of the dApp and can hold ownership of digital assets on the base layer, including Ether, ERC-20 tokens, and NFTs.
 
 ### CartesiDAppFactory
-The [CartesiDAppFactory](../rollups-apis/json-rpc/application-factory.md) contract simplifies the deployment process for CartesiDApp contracts. It allows developers to deploy new CartesiDApp instances with a single function call, enhancing convenience and security. This factory approach ensures the deployed contract bytecode remains unaltered, assuring users and validators.
+The [CartesiDAppFactory](../api-reference/json-rpc/application-factory.md) contract simplifies the deployment process for CartesiDApp contracts. It allows developers to deploy new CartesiDApp instances with a single function call, enhancing convenience and security. This factory approach ensures the deployed contract bytecode remains unaltered, assuring users and validators.
 
 ### Portals
 
 Portal contracts facilitate the secure transfer of assets between the base layer and the Cartesi execution environment. Currently, Cartesi supports the following types of asset transfers:
 
-- [Ether (ETH)](../rollups-apis/json-rpc/portals/EtherPortal.md)
-- [ERC-20 (Fungible tokens)](../rollups-apis/json-rpc/portals/ERC20Portal.md)
-- [ERC-721 (Non-fungible tokens)](../rollups-apis/json-rpc/portals/ERC721Portal.md)
-- [ERC-1155 Single transfers](../rollups-apis/json-rpc/portals/ERC1155SinglePortal.md)
-- [ERC-1155 Batch transfers](../rollups-apis/json-rpc/portals/ERC1155BatchPortal.md)
+- [Ether (ETH)](../api-reference/json-rpc/portals/EtherPortal.md)
+- [ERC-20 (Fungible tokens)](../api-reference/json-rpc/portals/ERC20Portal.md)
+- [ERC-721 (Non-fungible tokens)](../api-reference/json-rpc/portals/ERC721Portal.md)
+- [ERC-1155 Single transfers](../api-reference/json-rpc/portals/ERC1155SinglePortal.md)
+- [ERC-1155 Batch transfers](../api-reference/json-rpc/portals/ERC1155BatchPortal.md)
 
 These Portal contracts implement the logic to "teleport" assets safely between layers, maintaining their integrity and ownership throughout the transfer process.
 
@@ -113,9 +113,9 @@ The `advance-state` process changes the application state, and it involves the f
 
 - The node sends the input to the application backend inside the Cartesi Machine.
 
-- The Cartesi Machine processes the input and generates verifiable outputs ([vouchers](../rollups-apis/backend/vouchers.md), [notices](../rollups-apis/backend/notices.md), and [reports](../rollups-apis/backend/reports.md)).
+- The Cartesi Machine processes the input and generates verifiable outputs ([vouchers](../api-reference/backend/vouchers.md), [notices](../api-reference/backend/notices.md), and [reports](../api-reference/backend/reports.md)).
 
-- The application frontend can query these outputs using the node's [GraphQL API](../rollups-apis/graphql/basics.md).
+- The application frontend can query these outputs using the node's [GraphQL API](../api-reference/graphql/basics.md).
 
 ### Inspect state
 
@@ -127,9 +127,9 @@ The `inspect-state` process allows for querying the application backend without
 
 - The node forwards this input to the Cartesi Machine.
 
-- The Cartesi Machine processes the input and generates a [report](../rollups-apis/backend/reports.md).
+- The Cartesi Machine processes the input and generates a [report](../api-reference/backend/reports.md).
 
-- The node returns this report to the frontend via a [REST API](../rollups-apis/backend/introduction.md/#advance-and-inspect).
+- The node returns this report to the frontend via a [REST API](../api-reference/backend/introduction.md/#advance-and-inspect).
 
 :::note Inspect requests
 It's important to note that `inspect-state` inputs do not produce vouchers or notices, and the current implementation processes inputs sequentially, which may impact scalability for applications heavily reliant on inspect-state functionality.

cartesi-rollups_versioned_docs/version-2.0/deployment/introduction.md

@@ -23,7 +23,7 @@ The `cartesi build` command produces the Cartesi genesis machine, which contains
 
 After deployment, any changes to the application code will generate a different hash and, hence, require another deployment.
 
-The smart contract that represents the application on the base layer can be deployed using the [`CartesiDAppFactory`](../rollups-apis/json-rpc/application-factory.md) smart contract.
+The smart contract that represents the application on the base layer can be deployed using the [`CartesiDAppFactory`](../api-reference/json-rpc/application-factory.md) smart contract.
 
 There are two methods to deploy an application:
 

cartesi-rollups_versioned_docs/version-2.0/deployment/self-hosted.md

@@ -93,7 +93,7 @@ Alternatively, you can use a service like [Fly.io](https://fly.io/) to deploy yo
 
   The connection string for a PostgreSQL database must be configured at the `CARTESI_POSTGRES_ENDPOINT` variable.
 
-  You can use any PostgreSQL database, whether managed by a cloud provider or set up on your local infrastructure. The key configuration required is the connection string, encompassing the database URL, username, password, and name. The node necessitates a PostgreSQL database to store the application state, which is accessible via the [GraphQL API](../rollups-apis/graphql/basics.md).
+  You can use any PostgreSQL database, whether managed by a cloud provider or set up on your local infrastructure. The key configuration required is the connection string, encompassing the database URL, username, password, and name. The node necessitates a PostgreSQL database to store the application state, which is accessible via the [GraphQL API](../api-reference/graphql/basics.md).
 
 1. With all the config variables set, here is how you can run the node on your local machine:
 

cartesi-rollups_versioned_docs/version-2.0/development/asset-handling.md

@@ -12,11 +12,11 @@ As with any execution layer solution, a Cartesi dApp that wants to manipulate as
 
 Currently, Cartesi Rollups support the following types of assets:
 
-- [Ether (ETH)](../rollups-apis/json-rpc/portals/)
-- [ERC-20](../rollups-apis/json-rpc/portals/ERC20Portal.md)
-- [ERC-721](../rollups-apis/json-rpc/portals/ERC721Portal.md)
-- [ERC-1155 Single](../rollups-apis/json-rpc/portals/ERC1155SinglePortal.md)
-- [ERC-1155 Batch](../rollups-apis/json-rpc/portals/ERC1155BatchPortal.md)
+- [Ether (ETH)](../api-reference/json-rpc/portals/EtherPortal.md)
+- [ERC-20](../api-reference/json-rpc/portals/ERC20Portal.md)
+- [ERC-721](../api-reference/json-rpc/portals/ERC721Portal.md)
+- [ERC-1155 Single](../api-reference/json-rpc/portals/ERC1155SinglePortal.md)
+- [ERC-1155 Batch](../api-reference/json-rpc/portals/ERC1155BatchPortal.md)
 
 ![img](../../../static/img/v1.3/assets.jpg)
 
@@ -50,7 +50,7 @@ Vouchers are crucial in allowing dApps in the execution layer to interact with c
 
 The dApp’s off-chain layer often requires knowledge of its address to facilitate on-chain interactions for withdrawals, for example: `transferFrom(sender, recipient, amount)`. In this case, the sender is the dApp itself.
 
-By calling [`relayDAppAddress()`](../rollups-apis/json-rpc/relays/relays.md), function of the `DAppAddressRelay` contract, it adds the dApp’s address as a new input for the Cartesi dApp to process. Next, the off-chain machine uses this address to generate a voucher for execution at the [`executeVoucher()`](../rollups-apis/json-rpc/application.md/#executevoucher) function of the `CartesiDApp` contract.
+By calling [`relayDAppAddress()`](../api-reference/json-rpc/relays/relays.md), function of the `DAppAddressRelay` contract, it adds the dApp’s address as a new input for the Cartesi dApp to process. Next, the off-chain machine uses this address to generate a voucher for execution at the [`executeVoucher()`](../api-reference/json-rpc/application.md/#executevoucher) function of the `CartesiDApp` contract.
 
 :::note epoch length
 By default, Cartesi nodes close one epoch every 7200 blocks. You can [manually set the epoch length](./cli-commands.md/#run) to facilitate quicker asset-handling methods.
@@ -60,7 +60,7 @@ Here are the function signatures used by vouchers to withdraw the different type
 
 | Asset    | Destination    | Function signature                                                                                                                          |
 | :------- | :------------- | :------------------------------------------------------------------------------------------------------------------------------------------ |
-| Ether    | dApp contract  | `withdrawEther(address,uint256)` [:page_facing_up:](../rollups-apis/json-rpc/application.md/#withdrawether)                            |
+| Ether    | dApp contract  | `withdrawEther(address,uint256)` [:page_facing_up:](../api-reference/json-rpc/application.md/#withdrawether)                            |
 | ERC-20   | Token contract | `transfer(address,uint256)` [:page_facing_up:](https://eips.ethereum.org/EIPS/eip-20#methods)                                               |
 | ERC-20   | Token contract | `transferFrom(address,address,uint256)` [:page_facing_up:](https://eips.ethereum.org/EIPS/eip-20#methods)                                   |
 | ERC-721  | Token contract | `safeTransferFrom(address,address,uint256)` [:page_facing_up:](https://eips.ethereum.org/EIPS/eip-721#specification)                        |

cartesi-rollups_versioned_docs/version-2.0/development/query-outputs.md

@@ -20,7 +20,7 @@ Think of it as a digital authorization ticket that enables a dApp to perform spe
 
 - The voucher specifies the action, such as a token swap, and is sent to the blockchain.
 
-- The [`CartesiDApp`](../rollups-apis/json-rpc/application.md) contract executes the voucher using the [`executeVoucher()`](../rollups-apis/json-rpc/application.md/#executevoucher) function.
+- The [`CartesiDApp`](../api-reference/json-rpc/application.md) contract executes the voucher using the [`executeVoucher()`](../api-reference/json-rpc/application.md/#executevoucher) function.
 
 - The result is recorded on the base layer through claims submitted by a consensus contract.
 
@@ -40,7 +40,7 @@ They serve as a means for dApp to notify the blockchain about particular events.
 
 - The notice is submitted to the Rollup Server as evidence of the off-chain event.
 
-- Notices are validated on-chain using the [`validateNotice()`](../rollups-apis/json-rpc/application.md/#validatenotice) function of the [`CartesiDApp`](../rollups-apis/json-rpc/application.md) contract.
+- Notices are validated on-chain using the [`validateNotice()`](../api-reference/json-rpc/application.md/#validatenotice) function of the [`CartesiDApp`](../api-reference/json-rpc/application.md) contract.
 
 
 ### Send a notice

cartesi-rollups_versioned_docs/version-2.0/development/send-inputs.md

@@ -137,7 +137,7 @@ Advance requests involve sending input data to the L1 through a JSON-RPC call, a
 
 In the dApp architecture, here is how an advance request plays out.
 
-- Step 1: Send an input to the [`addInput(address, bytes)`](../rollups-apis/json-rpc/input-box.md/#addinput) function of the InputBox smart contract.
+- Step 1: Send an input to the [`addInput(address, bytes)`](../api-reference/json-rpc/input-box.md/#addinput) function of the InputBox smart contract.
 
 - Step 2: The Cartesi Node reads the data and gives it to the Cartesi machine for processing.
 

cartesi-rollups_versioned_docs/version-2.0/getting-started/index.md

@@ -31,7 +31,7 @@ In its simplest form, the Cartesi framework integrates tightly with the base lay
 
 ## Example
 
-Below is a simple Node.js example demonstrating how to read an input and reply with a [notice](../rollups-apis/backend/notices.md) (a type of output).
+Below is a simple Node.js example demonstrating how to read an input and reply with a [notice](../api-reference/backend/notices.md) (a type of output).
 
 ```javascript
 const { ethers } = require("ethers");
@@ -57,7 +57,7 @@ let finish = { status: "accept" };
 
 ```
 
-Cartesi dApps are implemented as infinite loops that manage their transaction cycles through HTTP POST requests to the `/finish` endpoint to ensure flexibility across different programming languages and stacks. You can learn more about this abstraction [here](../rollups-apis/backend/introduction.md).
+Cartesi dApps are implemented as infinite loops that manage their transaction cycles through HTTP POST requests to the `/finish` endpoint to ensure flexibility across different programming languages and stacks. You can learn more about this abstraction [here](../api-reference/backend/introduction.md).
 
 In the Cartesi Rollup framework, all inputs sent to the base layer trigger an "advance_state" [request](../development/send-inputs.md#initiate-an-advance-request), which alters the state of the Cartesi Machine and consequently the Rollup. Since inputs originate on-chain, they are hex-encoded following the EVM message standard.
 

cartesi-rollups_versioned_docs/version-2.0/tutorials/ether-wallet.md

@@ -271,7 +271,7 @@ The `encodeWithdrawCall` method returns a voucher. Creating vouchers is a crucia
 
 The voucher creation process occurs during Ether’s withdrawal. Here's how it works in this application:
 
-1. The `encodeFunctionData` function creates the calldata for the [`function withdrawEther(address _receiver, uint256 _value) external`](../rollups-apis/json-rpc/application.md/#withdrawether) on the `CartesiDApp` contract.
+1. The `encodeFunctionData` function creates the calldata for the [`function withdrawEther(address _receiver, uint256 _value) external`](../api-reference/json-rpc/application.md/#withdrawether) on the `CartesiDApp` contract.
 
 It returns a Voucher object with two properties:
 
@@ -288,9 +288,9 @@ It returns a Voucher object with two properties:
 
 Now, let's create a simple application at the entry point, `src/index.ts,` to test the wallet functionality.
 
-The [`EtherPortal`](../rollups-apis/json-rpc/portals/EtherPortal.md) contract allows anyone to perform transfers of Ether to a dApp. All deposits to a dApp are made via the `EtherPortal` contract.
+The [`EtherPortal`](../api-reference/json-rpc/portals/EtherPortal.md) contract allows anyone to perform transfers of Ether to a dApp. All deposits to a dApp are made via the `EtherPortal` contract.
 
-The [`DAppAddressRelay`](../rollups-apis/json-rpc/relays/relays.md) contract provides the critical information (the dApp's address) that the voucher creation process needs to function correctly. Without this relay mechanism, the off-chain part of the dApp wouldn't know its on-chain address, making it impossible to create valid vouchers for withdrawals.
+The [`DAppAddressRelay`](../api-reference/json-rpc/relays/relays.md) contract provides the critical information (the dApp's address) that the voucher creation process needs to function correctly. Without this relay mechanism, the off-chain part of the dApp wouldn't know its on-chain address, making it impossible to create valid vouchers for withdrawals.
 
 :::note
 Run `cartesi address-book` to get the addresses of the `EtherPortal` and `DAppAddressRelay` contracts. Save these as constants in the `index.ts` file.
@@ -536,4 +536,4 @@ For end-to-end functionality, developers will likely build their [custom user-fa
 
 When you run your application with `cartesi run`, there is a local instance of CartesiScan on `http://localhost:8080/explorer`.
 
-You can execute your vouchers via the explorer, which completes the withdrawal process at the end of [an epoch](../rollups-apis/backend/vouchers.md/#epoch-configuration).
+You can execute your vouchers via the explorer, which completes the withdrawal process at the end of [an epoch](../api-reference/backend/vouchers.md/#epoch-configuration).