# Migrating

## From v1 to v2

Deroll v1 is based on Cartesi Rollups v1, while deroll v2 is based on Cartesi Rollups v2.

Here are the changes you should be aware of when migrating from v1 to v2:

### Rollup transport

Deroll v1 communicates with the Cartesi Machine through the **Rollup HTTP Server**, so `createApp` required its `url`:

```ts
// v1
const app = createApp({ url: "http://127.0.0.1:5004" });
```

Deroll v2 talks to the machine directly through a native Node.js binding instead of polling the HTTP server, so `createApp` no longer takes a `url`:

```ts
// v2
const app = createApp();
```

The `ROLLUP_HTTP_SERVER_URL` environment variable is no longer used. The only remaining option is [`broadcastAdvanceRequests`](/app/create-app), which is unchanged.

### Input metadata

The input metadata received in an advance handler has changed.

```diff
-chain_id: number;
-msg_sender: Address;
-epochIndex: bigint;
-input_index: number;
-block_number: number;
-timestamp: number;
+chainId: bigint;
+appContract: Address;
+msgSender: Address;
+index: bigint;
+blockNumber: bigint;
+blockTimestamp: bigint;
+prevRandao: bigint;
```

### Payload type

The input payload the application should handle in advance handlers and inspect handlers are now a Node.js [Buffer](https://nodejs.org/api/buffer.html#class-buffer) instead of a `Hex` string.

### Voucher value

Vouchers now have an optional bigint `value` field, which is the amount of native token to be sent during voucher execution.
With this new property withdraw vouchers can now be much simpler.

```ts twoslash
import { createApp } from "@deroll/app";
import { encodeFunctionData, erc20Abi, parseUnits } from "viem";

// create application
const app = createApp();

// log incoming advance request
app.addAdvanceHandler(async (data) => {
    const token = "0x491604c0FDF08347Dd1fa4Ee062a822A5DD06B5D"; // CTSI address
    const to = "0x8f7599fa6fDDF2845a3beBcDCb055C7Ba1793a1f"; // CTSI recipient
    const amount = parseUnits("1", 18);

    const id = await app.createVoucher({
        destination: token,
        payload: encodeFunctionData({
            abi: erc20Abi,
            functionName: "transfer",
            args: [to, amount],
        }),
        value: 1000000000000000000n, // [!code focus]
    });
    return "accept";
});
```

### Change in ERC-20 deposit input

The message format of a ERC-20 deposit dropped the byte of the success flag.
If you use the `@deroll/wallet` module this change is automatically handled for you.

### DAppAddressRelay removed

Now that the input metadata includes the application address there is no need to use the `DAppAddressRelay` contract anymore.

### Delegate-call vouchers

Cartesi Rollups v2 introduces a new output type, the **delegate-call voucher**, which the application contract executes with `DELEGATECALL` instead of `CALL`, running the target code in the application's own context.
Deroll v2 exposes it through [`createDelegateCallVoucher`](/app/create-delegate-call-voucher).

### Executing outputs on the base layer

In v1 each output type had its own entry point on the `CartesiDApp` contract (for example `executeVoucher`).
In Cartesi Rollups v2 all outputs — vouchers, delegate-call vouchers and notices — share a single Merkle tree and are executed and validated through unified functions on the application contract:

```solidity
function executeOutput(bytes output, OutputValidityProof proof);
function validateOutput(bytes output, OutputValidityProof proof);
```

This mainly affects the frontend or relayer code that executes vouchers, not the advance and inspect handlers you write with deroll.

### GraphQL service deprecated

In v1 the inputs and outputs (notices, vouchers and reports) of an application were queried through a **GraphQL service**.
In v2 the GraphQL service is deprecated in favor of a [JSON-RPC API](/quick-start#querying-json-rpc) (for example `cartesi_listInputs`).
This is a frontend or off-chain concern and does not affect the advance and inspect handlers you write with deroll.