### Setup and Run Nexis Devnet (Bash)

Source: https://context7.com/nexis-ai/nexis-appchain/llms.txt

This bash script automates the setup and execution of a local Nexis Appchain development network. It clones the repository, installs dependencies using pnpm, builds the monorepo, and starts the full rollup stack. It then waits for services, checks the RPC, loads deployment addresses, queries a contract, runs integration tests, and finally shuts down the devnet.

```bash
#!/bin/bash
# Complete devnet setup script

# Clone repository
git clone https://github.com/Nexis-AI/nexis-appchain.git
cd nexis-appchain

# Install dependencies
corepack enable
corepack prepare pnpm@latest --activate
pnpm install

# Build entire monorepo
pnpm build

# Start devnet (sequencer, batcher, proposer, challenger, + Nexis contracts)
pnpm dev &

# Wait for services to be ready
sleep 30

# Check rollup RPC
curl -X POST http://127.0.0.1:9545 \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

# Load deployment addresses
DEPLOYMENT_FILE=".agents-devnet/agents-deployment.json"
AGENTS_ADDR=$(jq -r '.agents' $DEPLOYMENT_FILE)
TASKS_ADDR=$(jq -r '.tasks' $DEPLOYMENT_FILE)
TREASURY_ADDR=$(jq -r '.treasury' $DEPLOYMENT_FILE)
SUBSCRIPTIONS_ADDR=$(jq -r '.subscriptions' $DEPLOYMENT_FILE)

echo "Nexis Contracts Deployed:"
echo "  Agents:        $AGENTS_ADDR"
echo "  Tasks:         $TASKS_ADDR"
echo "  Treasury:      $TREASURY_ADDR"
echo "  Subscriptions: $SUBSCRIPTIONS_ADDR"

# Query bootstrap agent (auto-registered during deploy)
cast call $AGENTS_ADDR "agentOwner(uint256)(address)" 1 --rpc-url http://127.0.0.1:9545

# Run integration tests
./scripts/agents-devnet/hardhat-test.sh

# Shutdown devnet
pnpm dev:down
rm -rf .agents-devnet
```

--------------------------------

### Clean Install and Build Project

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/CONTRIBUTING.md

Performs a clean installation and build of the project, often used when encountering persistent issues. This involves cleaning the project, reinstalling dependencies, building the project, and restarting Docker services.

```bash
cd optimism
pnpm clean
pnpm install
pnpm build
cd ops
docker compose down -v
docker compose build
docker compose up
```

--------------------------------

### Install Geth and Prepare Devnet Allocations

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/op-e2e/README.md

These commands are used to install the Geth client, prepare the cannon pre-state, and generate devnet allocations. These steps are crucial for creating the genesis state required by the op-e2e tests.

```bash
make install-geth
make cannon-prestate
make devnet-allocs
```

--------------------------------

### Run a Specific Chain Monitoring Service

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/packages/chain-mon/README.md

This example shows how to run a specific chain monitoring service like 'drippie-mon'. It involves copying an example environment file, setting necessary environment variables, and then executing the start command for the desired service using pnpm.

```bash
cp .env.example .env
# Set environment variables here
pnpm start:drippie-mon
```

--------------------------------

### Go Build Environment Setup (Shell)

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/README.md

Shell commands to set up the Go environment for building private modules.

```shell
export GO111MODULE=on
go env -w GOPRIVATE=github.com/ethereum-optimism
```

--------------------------------

### Build TypeScript Packages and Smart Contracts

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/CONTRIBUTING.md

These commands clean previous builds, install dependencies, and then build all TypeScript packages and compile smart contracts using pnpm. Recompilation is necessary when switching branches.

```bash
pnpm clean
pnpm install
pnpm build
```

--------------------------------

### Install Node Modules with pnpm

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/CONTRIBUTING.md

This command installs all the necessary node modules for the project using the pnpm package manager. It's a crucial step after cloning the repository to ensure all dependencies are met.

```bash
pnpm i
```

--------------------------------

### Run Unit Tests (Go)

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/CONTRIBUTING.md

Executes unit tests for Go packages. Navigate to the package directory and run the `go test` command to test all sub-packages.

```shell
go test ./...
```

--------------------------------

### Run Fault Detector Service

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/packages/chain-mon/src/fault-mon/README.md

Starts the fault-mon service after configuring environment variables. Ensure `.env` is properly set up with necessary credentials and addresses.

```bash
pnpm start
```

--------------------------------

### Make Target Execution (Shell)

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/README.md

Example of using make targets for common development flows.

```shell
make devnet-up
```

--------------------------------

### Clone, Install, and Build Monorepo with pnpm

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/README.md

This bash script clones the Nexis Appchain repository, navigates into the directory, and installs dependencies and builds the project using pnpm. It's essential for setting up the development environment. `pnpm build` compiles Go binaries, TypeScript packages, and Solidity artifacts.

```bash
git clone https://github.com/Nexis-AI/nexis-appchain.git
cd nexis-appchain
pnpm install
pnpm build
```

--------------------------------

### Install OP Stack Contracts in Solidity (npm)

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/packages/contracts-bedrock/README.md

This command installs the OP Stack smart contracts package for use in Solidity projects. It allows developers to integrate system contracts into their dApps. Ensure you have Node.js and npm installed.

```sh
npm install @eth-optimism/contracts-bedrock.
```

--------------------------------

### Install OP Stack Contracts in JavaScript (npm)

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/packages/contracts-bedrock/README.md

This command installs the package containing ABIs and addresses for OP Stack smart contracts, enabling their use in JavaScript applications. Node.js and npm are prerequisites for this installation.

```sh
npm install @eth-optimism/contracts-ts
```

--------------------------------

### Build rethdb-reader dylib with Cargo

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/op-service/rethdb-reader/README.md

Builds the rethdb-reader dylib in release mode. Requires the Rust Toolchain to be installed.

```shell
cargo build --release
```

--------------------------------

### Fault Detector Command Line Help

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/packages/chain-mon/src/fault-mon/README.md

Displays help information for the fault-mon service, detailing available options for L1/L2 RPC providers, start batch index, loop interval, OptimismPortal address, port, hostname, and general help.

```bash
> pnpm start --help
$ tsx ./src/service.ts --help
Usage: service [options]

Options:
  --l1rpcprovider    Provider for interacting with L1 (env: FAULT_DETECTOR__L1_RPC_PROVIDER)
  --l2rpcprovider    Provider for interacting with L2 (env: FAULT_DETECTOR__L2_RPC_PROVIDER)
  --startbatchindex  Batch index to start checking from. Setting it to -1 will cause the fault detector to find the first state batch index that has not yet passed the fault proof window (env: FAULT_DETECTOR__START_BATCH_INDEX, default value: -1)
  --loopintervalms   Loop interval in milliseconds (env: FAULT_DETECTOR__LOOP_INTERVAL_MS)
  --optimismportaladdress        [Custom OP Chains] Deployed OptimismPortal contract address. Used to retrieve necessary info for output verification  (env: FAULT_DETECTOR__OPTIMISM_PORTAL_ADDRESS, default 0x0)

  --port             Port for the app server (env: FAULT_DETECTOR__PORT)
  --hostname         Hostname for the app server (env: FAULT_DETECTOR__HOSTNAME)
  -h, --help         display help for command

Metrics:
  highest_checked_batch_index   Highest good batch index (type: Gauge)
  highest_known_batch_index     Highest known batch index (type: Gauge)
  is_currently_mismatched       0 if state is ok, 1 if state is mismatched (type: Gauge)
  l1_node_connection_failures   Number of times L1 node connection has failed (type: Gauge)
  l2_node_connection_failures   Number of times L2 node connection has failed (type: Gauge)
  metadata                      Service metadata (type: Gauge)
  unhandled_errors              Unhandled errors (type: Counter)
```

--------------------------------

### Install and Build Optimism Monorepo using pnpm

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/packages/chain-mon/README.md

This code snippet demonstrates the commands required to clone the Optimism monorepo, install its dependencies using pnpm, and build the project. It's a prerequisite for running any of the chain monitoring services.

```bash
git clone https://github.com/ethereum-optimism/optimism.git
pnpm install
pnpm build
```

--------------------------------

### Clone and Navigate Optimism Monorepo

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/CONTRIBUTING.md

This snippet shows how to clone the Optimism monorepo using SSH and then navigate into the newly created directory. It's the initial step for setting up a local development environment.

```bash
git clone git@github.com:ethereum-optimism/optimism.git
cd optimism
```

--------------------------------

### Example JSON RPC Response for Consensus Get Receipts

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/proxyd/README.md

An example of a JSON RPC response from the `consensus_getReceipts` meta method. The response includes the method used to fetch the receipts from the backend and the actual result obtained from that backend. This structure helps abstract the underlying backend implementation details.

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "method": "debug_getRawReceipts",
    "result": {
      // the actual raw result from backend
    }
  }
}
```

--------------------------------

### Run Contract Static Analysis with Slither

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/CONTRIBUTING.md

Performs static analysis on smart contracts using Slither. Requires Python 3.x and the `slither-analyzer` package. It's typically run after installing dependencies and within the contracts package directory.

```bash
cd packages/contracts-bedrock
pip3 install slither-analyzer
pnpm slither
```

--------------------------------

### Deployment Script for Devnet

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/README.md

This bash script is used to bring up the agents devnet. It automates the process of starting the necessary services and potentially deploying contracts or funding accounts.

```bash
# Reference to scripts/agents-devnet/up.sh
```

--------------------------------

### Start op-node Syncing Rollup

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/op-node/README.md

Starts the op-node to sync the rollup. Requires connection to L1 and L2 RPC endpoints, and a rollup configuration file. Websockets or IPC are preferred for L1 and L2 connections for better performance.

```shell
# websockets or IPC preferred for event notifications to improve sync, http RPC works with adaptive polling.
op \
  --l1=ws://localhost:8546 --l2=ws//localhost:9001 \
  --rollup.config=./path-to-network-config/rollup.json \
  --rpc.addr=127.0.0.1 \
  --rpc.port=7000
```

--------------------------------

### Build System with Docker Compose

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/CONTRIBUTING.md

Builds the entire system using Docker Compose. This is necessary for running Optimism nodes and integration tests. Environment variables are used to speed up the build process.

```bash
cd ops-bedrock
export COMPOSE_DOCKER_CLI_BUILD=1
export DOCKER_BUILDKIT=1
docker compose build
```

--------------------------------

### Build and Run Cannon CLI with Op-Program Client

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/cannon/README.md

This section details the process of building the Cannon CLI and the op-program server-mode binary, then transforming the MIPS op-program client into an initial VM state. It also covers running the Cannon emulator with example inputs, connecting to L1 and L2 RPC endpoints, and specifying state and configuration for the execution.

```shell
# Build op-program server-mode and MIPS-client binaries.
cd ../op-program
make op-program # build

# Switch back to cannon, and build the CLI
cd ../cannon
make cannon

# Transform MIPS op-program client binary into first VM state.
# This outputs state.json (VM state) and meta.json (for debug symbols).
./bin/cannon load-elf --path=../op-program/bin/op-program-client.elf

# Run cannon emulator (with example inputs)
# Note that the server-mode op-program command is passed into cannon (after the --), 
# it runs as sub-process to provide the pre-image data.
#
# Note:
#  - The L2 RPC is an archive L2 node on OP goerli.
#  - The L1 RPC is a non-archive RPC, also change `--l1.rpckind` to reflect the correct L1 RPC type.
./bin/cannon run \
    --pprof.cpu \
    --info-at '%10000000' \
    --proof-at never \
    --input ./state.json \
    -- \
    ../op-program/bin/op-program \
    --network goerli \
    --l1.trustrpc \
    --l1.rpckind debug_geth \
    --l1 http://127.0.0.1:8645 \
    --l2 http://127.0.0.1:8745 \
    --l1.head 0x204f815790ca3bb43526ad60ebcc64784ec809bdc3550e82b54a0172f981efab \
    --l2.head 0xedc79de4d616a9100fdd42192224580daee81ea3d6303de8089d48a6c1bf4816 \
    --l2.claim 0x530658ab1b1b3ff4829731fc8d5955f0e6b8410db2cd65b572067ba58df1f2b9 \
    --l2.blocknumber 8813570 \
    --datadir /tmp/fpp-database \
    --log.format terminal \
    --server

# Add --proof-at '=12345' (or pick other pattern, see --help)
# to pick a step to build a proof for (e.g. exact step, every N steps, etc.)

# Also see `./bin/cannon run --help` for more options

```

--------------------------------

### Troubleshooting Devnet Start Issues (Shell)

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/README.md

Shell command to stop existing devnet containers before retrying startup.

```shell
pnpm dev:down
```

--------------------------------

### TypeScript Example for Monitoring Streams

Source: https://context7.com/nexis-ai/nexis-appchain/llms.txt

Provides a TypeScript example using ethers.js to monitor payment streams. It demonstrates how to connect to a blockchain provider, interact with the ISubscriptions contract to retrieve stream details, and calculate withdrawable amounts. This snippet is useful for building external applications that need to track the status of payment streams.

```typescript
// TypeScript example for stream monitoring
import { ethers } from 'ethers';

interface StreamInfo {
    ratePerSecond: bigint;
    start: bigint;
    end: bigint;
    deposited: bigint;
    withdrawn: bigint;
    active: boolean;
}

async function monitorStream(streamId: number) {
    const provider = new ethers.JsonRpcProvider('http://127.0.0.1:9545');
    const wallet = new ethers.Wallet(process.env.PRIVATE_KEY!, provider);

    const subscriptionsAbi = [
        'function getStream(uint256) view returns (tuple(address payer, uint256 agentId, address asset, uint256 ratePerSecond, uint64 start, uint64 end, uint256 deposited, uint256 withdrawn, bool active, string integrationURI))',
        'function withdrawFromStream(uint256)',
        'event StreamWithdrawn(uint256 indexed streamId, address indexed recipient, uint256 amount)'
    ];

    const subscriptions = new ethers.Contract('0x...', subscriptionsAbi, wallet);

    // Query stream details
    const stream: StreamInfo = await subscriptions.getStream(streamId);
    console.log(`Stream ${streamId}:
`);
    console.log(`  Rate: ${ethers.formatEther(stream.ratePerSecond)} ETH/second
`);
    console.log(`  Period: ${stream.start} to ${stream.end}
`);
    console.log(`  Deposited: ${ethers.formatEther(stream.deposited)} ETH
`);
    console.log(`  Withdrawn: ${ethers.formatEther(stream.withdrawn)} ETH
`);

    // Calculate withdrawable amount

```

--------------------------------

### Start and Stop Local Devnet with pnpm

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/README.md

These bash commands manage the local Nexis Base L3 devnet. `pnpm dev` spins up the Bedrock stack via Docker Compose, generates config snapshots, and deploys contracts. `pnpm dev:down` stops the stack. The `sleep 20` ensures the devnet has sufficient time to initialize.

```bash
pnpm dev &
```

```bash
sleep 20
```

```bash
pnpm dev:down
```

```bash
rm -rf .agents-devnet  # optional cleanup
```

--------------------------------

### Run All Unit Tests (TypeScript)

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/CONTRIBUTING.md

Executes all unit tests for all packages in parallel using pnpm. This is a quick way to ensure the integrity of the entire codebase.

```bash
pnpm test
```

--------------------------------

### Generate C header for rethdb-reader with cbindgen

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/op-service/rethdb-reader/README.md

Generates the C header file for the rethdb-reader dylib using cbindgen. Requires cbindgen to be installed via cargo.

```shell
./headgen.sh
```

--------------------------------

### Cast CLI for Task Management Operations

Source: https://context7.com/nexis-ai/nexis-appchain/llms.txt

Demonstrates how to interact with the task smart contracts using the `cast` command-line tool. Includes examples for posting a task, claiming a task as an agent, and querying the status of a task.

```bash
# Post a task via cast
TASK_ID=$(cast send $TASKS_CONTRACT \
  "postTask(address,uint256,uint256,uint64,uint64,string,string)" \
  0x0000000000000000000000000000000000000000 \
  100000000000000000 \
  500000000000000000 \
  3600 \
  21600 \
  "ipfs://QmTaskMeta/task.json" \
  "ipfs://QmInput/data.json" \
  --value 0.1ether \
  --private-key $PRIVATE_KEY \
  --rpc-url http://127.0.0.1:9545 | grep "taskId" | cut -d' ' -f2)

echo "Task created: $TASK_ID"

# Agent claims task
cast send $TASKS_CONTRACT "claimTask(uint256,uint256)" $TASK_ID 12345 \
  --private-key $AGENT_PRIVATE_KEY \
  --rpc-url http://127.0.0.1:9545

# Query task status
cast call $TASKS_CONTRACT "getTask(uint256)" $TASK_ID --rpc-url http://127.0.0.1:9545

```

--------------------------------

### Mocking CI Execution with Act (Bash)

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/ufm-test-services/README.md

This snippet demonstrates how to use the 'act' tool to locally mock GitHub Actions workflows for testing the User Facing Monitoring (UFM) project. It requires Act installation, a GitHub token, and specific configuration in the .actrc file. The command executes a specified workflow, secrets file, and container architecture.

```bash
act -W .github/workflows/YOUR_WORKFLOW_FILE.yml -s GITHUB_TOKEN=YOUR_TOKEN --secret-file ./ufm-test-services/.secrets --container-architecture linux/amd64
```

--------------------------------

### Merkle Proof Verification Logic

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/cannon/docs/README.md

Illustrates the logic for verifying a Merkle proof in the binary Merkle tree. It starts with a leaf value and iteratively combines it with sibling nodes up to the root.

```Python
def verify_proof(leaf_value, siblings, target_root):
    node = leaf_value
    for i, sibling in enumerate(siblings):
        # Determine if node is left or right child based on level or position
        # For simplicity, assuming a consistent ordering or a flag is passed
        is_left_child = (i % 2 == 0) # Example logic, actual may differ
        if is_left_child:
            node = keccak256(node + sibling)
        else:
            node = keccak256(sibling + node)
    return node == target_root
```

```Solidity
function verifyProof(bytes32 leafValue, bytes32[] memory siblings, bytes32 root) internal pure returns (bool) {
    bytes32 node = leafValue;
    for (uint i = 0; i < siblings.length; i++) {
        // The actual implementation would need to know the position of the sibling
        // relative to the current node (left or right child). This is a placeholder.
        // Assuming 'siblings[i]' is always the correct sibling to combine with.
        // A real implementation might derive this from the proof structure or path.
        
        // Example: If we know 'node' is always the left child for demonstration
        // node = hashNode(node, siblings[i]); 
        
        // A more robust approach would involve checking bitmasks or path information
        // For this example, we'll simulate a possible combination:
        node = keccak256(abi.encodePacked(node, siblings[i])); // Simplified example
    }
    return node == root;
}
```

--------------------------------

### Run Docker Container with XQuartz on MacOS

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/ufm-test-services/metamask/README.md

Runs the 'ufm-test-service-metamask' Docker container on MacOS, enabling graphical output through XQuartz. Requires XQuartz to be installed and configured to allow network client connections and host access. The DISPLAY environment variable and X11 socket are mounted for inter-process communication.

```bash
docker run --rm -it \
-e DISPLAY=host.docker.internal:0 \
-v /tmp/.X11-unix:/tmp/.X11-unix \
ufm-test-service-metamask

```

--------------------------------

### Execute Proofs (Shell)

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/packages/contracts-bedrock/test/kontrol/README.md

Executes proofs defined in *.k.sol files using the run-kontrol.sh script. It supports three execution modes (container, local, dev) and two methods for specifying tests (script or specific test names). Using the 'tests' method allows targeting individual tests or all functions starting with 'test', 'prove', or 'check'.

```shell
./test/kontrol/scripts/run-kontrol.sh [container|local|dev] [script|tests]

```

--------------------------------

### Run Nexis Devnet and Integration Tests (JavaScript)

Source: https://context7.com/nexis-ai/nexis-appchain/llms.txt

This JavaScript code automates the process of deploying and running the Nexis devnet, then executing integration tests against it. It starts the devnet in the background, polls for the deployment file to confirm readiness, logs deployment details, sets necessary environment variables, and runs the Hardhat test suite. It uses Node.js's `child_process` and `fs` modules for executing shell commands and file system operations.

```javascript
// JavaScript deployment integration
const { execSync } = require('child_process');
const fs = require('fs');

async function deployDevnet() {
    console.log('Starting Nexis devnet...');

    // Start devnet in background
    execSync('pnpm dev &', { stdio: 'inherit' });

    // Poll for deployment file
    let attempts = 0;
    while (attempts < 60) {
        if (fs.existsSync('.agents-devnet/agents-deployment.json')) {
            const deployment = JSON.parse(
                fs.readFileSync('.agents-devnet/agents-deployment.json', 'utf8')
            );

            console.log('Devnet ready!');
            console.log('Chain ID:', deployment.chainId);
            console.log('RPC URL:', 'http://127.0.0.1:9545');
            console.log('Contracts:', {
                agents: deployment.agents,
                tasks: deployment.tasks,
                treasury: deployment.treasury,
                subscriptions: deployment.subscriptions
            });

            return deployment;
        }
        await new Promise(resolve => setTimeout(resolve, 1000));
        attempts++;
    }

    throw new Error('Devnet failed to start');
}

// Run tests against devnet
async function runTests() {
    const deployment = await deployDevnet();

    // Set environment variables for tests
    process.env.AGENTS_CONTRACT = deployment.agents;
    process.env.TASKS_CONTRACT = deployment.tasks;
    process.env.RPC_URL = 'http://127.0.0.1:9545';

    // Run test suite
    execSync('npx hardhat test --network agentsL3', { stdio: 'inherit' });
}
```

--------------------------------

### Review Op-Program Command-Line Help

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/op-program/README.md

Displays the available command-line options and usage instructions for the op-program executable. This command should be run from within the 'op-program' directory.

```shell
./bin/op-program --help
```

--------------------------------

### Configuring Cron Jobs for Local Scheduling (Bash)

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/ufm-test-services/README.md

This snippet provides example cron job configurations for scheduling the execution of Test Services locally on Linux/MacOS. It specifies the PATH to ensure Docker commands are found and defines schedules for hourly, daily, and weekly executions using Docker Compose profiles.

```bash
# Needs to point to docker, otherwise you'll get the error: exec: "docker": executable file not found in $PATH
PATH=/ 

# Runs every 1 hour
0 * * * * /usr/local/bin/docker-compose -f /path/to/docker-compose.yml --profile 1hour up -d

# Runs every 1 day
0 12 * * * /usr/local/bin/docker-compose -f /path/to/docker-compose.yml --profile 1day up -d

# Runs every 7 days
0 12 */7 * * /usr/local/bin/docker-compose -f /path/to/docker-compose.yml --profile 7day up -d
```

--------------------------------

### JavaScript Withdrawal Management with ethers.js

Source: https://context7.com/nexis-ai/nexis-appchain/llms.txt

An example JavaScript snippet demonstrating how to interact with the Nexis withdrawal contract using ethers.js. It shows how to initiate a withdrawal, check the unbonding period, and claim funds. This requires a configured ethers.js provider, wallet, and the contract's ABI and address.

```javascript
// JavaScript integration example using ethers.js
const { ethers } = require('ethers');

async function manageWithdrawals() {
    const provider = new ethers.JsonRpcProvider('http://127.0.0.1:9545');
    const wallet = new ethers.Wallet(process.env.PRIVATE_KEY, provider);

    const agentsAbi = [
        "function requestWithdrawal(uint256 agentId, address asset, uint256 amount)",
        "function claimWithdrawals(uint256 agentId, address asset, uint256 maxEntries, address receiver, bool forceEarly) returns (uint256, uint256)",
        "function pendingWithdrawalCount(uint256 agentId, address asset) view returns (uint256)",
        "function unbondingPeriod(address asset) view returns (uint64)"
    ];

    const agents = new ethers.Contract('0x...', agentsAbi, wallet);
    const agentId = 12345;
    const ETH_ASSET = ethers.ZeroAddress;

    // Request 0.5 ETH withdrawal
    const tx = await agents.requestWithdrawal(agentId, ETH_ASSET, ethers.parseEther('0.5'));
    await tx.wait();
    console.log('Withdrawal initiated');

    // Check unbonding period (7 days = 604800 seconds)
    const period = await agents.unbondingPeriod(ETH_ASSET);
    console.log(`Unbonding period: ${period} seconds`);

    // Wait for unbonding period, then claim
    const pendingCount = await agents.pendingWithdrawalCount(agentId, ETH_ASSET);
    console.log(`Pending withdrawals: ${pendingCount}`);

    // Claim all mature withdrawals
    const claimTx = await agents.claimWithdrawals(agentId, ETH_ASSET, 0, wallet.address, false);
    const receipt = await claimTx.wait();
    console.log('Withdrawals claimed');
}

```

--------------------------------

### Build and Run Op-Challenger with Cannon on Local Devnet (Shell)

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/op-challenger/README.md

This snippet demonstrates the commands to build the op-challenger and then run it against a local devnet using the Cannon trace type. It requires setting up the devnet first and configures the challenger with various RPC endpoints, game factory addresses, and Cannon-specific paths.

```shell
make devnet-clean
make devnet-up
make op-challenger

DISPUTE_GAME_FACTORY=$(jq -r .DisputeGameFactoryProxy .devnet/addresses.json)
./op-challenger/bin/op-challenger \
  --trace-type cannon \
  --l1-eth-rpc http://localhost:8545 \
  --rollup-rpc http://localhost:9546 \
  --game-factory-address $DISPUTE_GAME_FACTORY \
  --datadir temp/challenger-data \
  --cannon-rollup-config .devnet/rollup.json  \
  --cannon-l2-genesis .devnet/genesis-l2.json \
  --cannon-bin ./cannon/bin/cannon \
  --cannon-server ./op-program/bin/op-program \
  --cannon-prestate ./op-program/bin/prestate.json \
  --l2-eth-rpc http://localhost:9545 \
  --mnemonic "test test test test test test test test test test test junk" \
  --hd-path "m/44'/60'/0'/0/8" \
  --num-confirmations 1
```

--------------------------------

### Build and Run op-upgrade CLI Tool

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/op-chain-ops/cmd/op-upgrade/README.md

This snippet shows how to build and execute the op-upgrade CLI tool using the provided Makefile. It demonstrates the command structure for creating a Safe transaction bundle, specifying essential configuration parameters like L1 RPC URL, target chain IDs, superchain target, output file, and deploy configuration directory.

```bash
make op-upgrade
./bin/op-upgrade \
  --l1-rpc-url https://ethereum-rpc.publicnode.com  \
  --chain-ids 10 \
  --superchain-target mainnet \
  --outfile input.json \
  --deploy-config ../packages/contracts-bedrock/deploy-config
```

--------------------------------

### Build and Run op-challenger

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/docs/fault-proof-alpha/run-challenger.md

This snippet demonstrates the build process for the op-challenger and its dependencies, followed by the command to run op-challenger with specific configuration parameters for the Goerli testnet. It requires placeholders for L1 and L2 RPC endpoints, contract addresses, prestate files, and private keys.

```bash
# Build the required components
make op-challenger op-program cannon

# Run op-challenger
./op-challenger/bin/op-challenger \
  --trace-type cannon \
  --l1-eth-rpc <L1_URL> \
  --game-factory-address <DISPUTE_GAME_FACTORY_ADDRESS> \
  --datadir temp/challenger-goerli \
  --cannon-network goerli \
  --cannon-bin ./cannon/bin/cannon \
  --cannon-server ./op-program/bin/op-program \
  --cannon-prestate <PRESTATE> \
  --l2-eth-rpc <L2_URL> \
  --private-key <PRIVATE_KEY>
```

--------------------------------

### Example JSON RPC Request for Consensus Get Receipts

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/proxyd/README.md

An example of a JSON RPC request to the `consensus_getReceipts` meta method, which abstracts away the specific backend used for fetching transaction receipts for a given block number or hash. This method supports translation to various backend-specific receipt fetching targets.

```json
{
  "jsonrpc":"2.0",
  "id": 1,
  "params": ["0xc6ef2fc5426d6ad6fd9e2a26abeab0aa2411b7ab17f30a99d3cb96aed1d1055b"]
}
```

--------------------------------

### View Specific Docker Container Logs

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/CONTRIBUTING.md

Follows the logs of a specific service within a Docker Compose setup. This is useful for filtering and monitoring individual container output.

```bash
docker compose logs --follow <service name>
```

--------------------------------

### Display op-node Help Information

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/op-node/README.md

Displays the help message for the op-node binary, listing available commands and options. This is useful for understanding how to configure and run the node.

```shell
./bin/op-node --help
```

--------------------------------

### Handle Missing Method JSON-RPC Error

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/proxyd/integration_tests/testdata/testdata.txt

This example illustrates a JSON-RPC request that is missing the required 'method' field. The server responds with an invalid request error (-32600) and indicates that no method was specified.

```json
{
  "jsonrpc": "2.0"
}
```

```json
{
  "jsonrpc": "2.0",
  "error": {
    "code": -32600,
    "message": "no method specified"
  },
  "id": null
}
```

--------------------------------

### Handle Missing Transaction Data Error

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/proxyd/integration_tests/testdata/testdata.txt

This example shows a valid JSON-RPC request for 'eth_sendRawTransaction' but with an empty 'params' array. The server responds with an invalid params error (-32602), indicating that a required argument is missing.

```json
{
  "jsonrpc": "2.0",
  "method": "eth_sendRawTransaction",
  "params": [],
  "id": 1
}
```

```json
{
  "jsonrpc": "2.0",
  "error": {
    "code": -32602,
    "message": "missing value for required argument 0"
  },
  "id": 1
}
```

--------------------------------

### Building Go Services (Shell)

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/README.md

Shell commands to build individual Go services or use a unified command for orchestrated builds.

```shell
go build ./op-node
go build ./op-proposer
pnpm build
```

--------------------------------

### Handle Pre-EIP-155 Transaction (Simple Send)

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/proxyd/integration_tests/testdata/testdata.txt

This example shows a 'eth_sendRawTransaction' request for a transaction signed without a chain ID (pre-EIP-155). The server successfully processes this and returns a dummy result, indicating support for legacy transaction formats.

```json
{
  "jsonrpc": "2.0",
  "method": "eth_sendRawTransaction",
  "params": [
    "0xf865808609184e72a00082271094000000000000000000000000000000000000000001001ba0d937ddb66e7788f917864b8e6974cac376b091154db1c25ff8429a6e61016e74a054ced39349e7658b7efceccfabc461e02418eb510124377949cfae8ccf1831af"
  ],
  "id": 1
}
```

```json
{
  "id": 123,
  "jsonrpc": "2.0",
  "result": "dummy"
}
```

--------------------------------

### Handle Invalid Transaction Data (Unsupported Type) Error

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/proxyd/integration_tests/testdata/testdata.txt

This example shows a request to 'eth_sendRawTransaction' with transaction data that represents an unsupported transaction type. The server returns an invalid params error (-32602) indicating the transaction type is not recognized.

```json
{
  "jsonrpc": "2.0",
  "method": "eth_sendRawTransaction",
  "params": [
    "0x1234"
  ],
  "id": 1
}
```

```json
{
  "jsonrpc": "2.0",
  "error": {
    "code": -32602,
    "message": "transaction type not supported"
  },
  "id": 1
}
```

--------------------------------

### Submit Contract Call Transaction (Valid JSON-RPC)

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/proxyd/integration_tests/testdata/testdata.txt

This example demonstrates a valid JSON-RPC request for submitting a raw transaction that performs a contract call. It follows the same structure as a simple send but with different transaction data specific to a contract interaction. The response confirms successful submission.

```json
{
  "jsonrpc": "2.0",
  "method": "eth_sendRawTransaction",
  "params": [
    "0x02f8b28201a406849502f931849502f931830147f9948f3ddd0fbf3e78ca1d6cd17379ed88e261249b5280b84447e7ef2400000000000000000000000089c8b1b2774201bac50f627403eac1b732459cf7000000000000000000000000000000000000000000000056bc75e2d63100000c080a0473c95566026c312c9664cd61145d2f3e759d49209fe96011ac012884ec5b017a0763b58f6fa6096e6ba28ee08bfac58f58fb3b8bcef5af98578bdeaddf40bde42"
  ],
  "id": 1
}
```

```json
{
  "id": 123,
  "jsonrpc": "2.0",
  "result": "dummy"
}
```

--------------------------------

### Compile op-node Binary

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/op-node/README.md

Compiles the op-node project into an executable binary. This command navigates to the op-node directory and uses the Go build tool to create an executable file named 'op-node' in the 'bin/' directory.

```shell
cd op-node
go build -o bin/op-node ./cmd
```

--------------------------------

### Run Op-Program Unit Tests using Make

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/op-program/README.md

Executes the unit tests for the op-program. This command should be run from within the 'op-program' directory.

```shell
make test
```

--------------------------------

### Bash CLI for Subscription Management

Source: https://context7.com/nexis-ai/nexis-appchain/llms.txt

Demonstrates using the 'cast' command-line tool to interact with the subscription smart contract. This includes creating a subscription, processing it after an epoch, and querying its details.

```bash
# Create subscription via CLI
SUB_ID=$(cast send $SUBSCRIPTIONS_CONTRACT \
  "createSubscription(uint256,address,uint256,uint64,uint8,string)" \
  12345 \
  0x0000000000000000000000000000000000000000 \
  10000000000000000 \
  86400 \
  30 \
  "ipfs://QmSubMeta/config.json" \
  --value 0.3ether \
  --private-key $PRIVATE_KEY \
  --rpc-url http://127.0.0.1:9545 | grep "subscriptionId" | cut -d' ' -f2)

echo "Subscription created: $SUB_ID"

# Process subscription after epoch elapses
cast send $SUBSCRIPTIONS_CONTRACT "processSubscription(uint256)" $SUB_ID \
  --private-key $PRIVATE_KEY \
  --rpc-url http://127.0.0.1:9545

# Query subscription details
cast call $SUBSCRIPTIONS_CONTRACT "getSubscription(uint256)" $SUB_ID --rpc-url http://127.0.0.1:9545

```

--------------------------------

### Create a New Fault Dispute Game (Shell)

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/op-challenger/README.md

This command initiates a new fault dispute game. It requires the L1 Ethereum RPC endpoint, the address of the dispute game factory, the proposed output root, and the L2 block number. Signer arguments are also necessary to authorize the transaction.

```shell
./bin/op-challenger create-game \
  --l1-eth-rpc <L1_ETH_RPC> \
  --game-address <GAME_FACTORY_ADDRESS> \
  --output-root <OUTPUT_ROOT> \
  --l2-block-num <L2_BLOCK_NUM> \
  <SIGNER_ARGS>
```

--------------------------------

### Update Foundry Installation

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/op-e2e/README.md

This command updates the Foundry toolchain to the latest version. Having the latest version of Foundry is a common troubleshooting step for test execution issues.

```bash
pnpm update:foundry
```

--------------------------------

### Spinning Up Monitoring Stack (Bash)

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/ufm-test-services/README.md

This command spins up the necessary containers for the monitoring stack (Pushgateway, Prometheus, Grafana) using Docker Compose. This is a prerequisite for both CI mocking and local execution when not using remote instances of these services.

```bash
docker-compose up pushgateway prometheus grafana
```

--------------------------------

### Running Test Services Manually (Bash)

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/ufm-test-services/README.md

This snippet shows how to manually run individual Test Services or groups of services defined in Docker Compose profiles. It requires copying the environment file and then using `docker-compose run` for a specific service or `docker-compose up` with a profile.

```bash
# Copy env file: cp .env.example .env
docker-compose run testService1
docker-compose --profile 1hour up
```

--------------------------------

### Compile Op-Program using Make

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/op-program/README.md

Compiles the op-program executable. This command should be run from within the 'op-program' directory. The output executable will be located at './bin/op-program'.

```shell
make op-program
```

--------------------------------

### Rebuild All Containers with Docker Compose

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/CONTRIBUTING.md

Rebuilds all Docker containers when source code changes affect multiple containers. This involves stopping, rebuilding, and restarting the services.

```bash
cd ops-bedrock
docker compose down
docker compose build
docker compose up
```

--------------------------------

### Run Cannon to Generate a Proof

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/docs/fault-proof-alpha/cannon.md

Executes the `cannon` program to generate a proof for a specific trace index. This command requires several configuration options, including pre-state, RPC endpoints for L1 and L2, block hashes, and output directories. The generated proof is stored in `temp/cannon/proofs/`.

```bash
mkdir -p temp/cannon/proofs temp/cannon/snapshots temp/cannon/preimages

./cannon/bin/cannon run \
    --pprof.cpu \
    --info-at '%10000000' \
    --proof-at '=<TRACE_INDEX>' \
    --stop-at '=<STOP_INDEX>' \
    --proof-fmt 'temp/cannon/proofs/%d.json' \
    --snapshot-at '%1000000000' \
    --snapshot-fmt 'temp/cannon/snapshots/%d.json.gz' \
    --input <PRESTATE> \
    --output temp/cannon/stop-state.json \
    -- \
    ./op-program/bin/op-program \
    --network goerli \
    --l1 <L1_URL> \
    --l2 <L2_URL> \
    --l1.head <L1_HEAD> \
    --l2.claim <L2_CLAIM> \
    --l2.head <L2_HEAD> \
    --l2.blocknumber <L2_BLOCK_NUMBER> \
    --datadir temp/cannon/preimages \
    --log.format terminal \
    --server
```

--------------------------------

### Run Unit Tests for a Specific Package (TypeScript)

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/CONTRIBUTING.md

Runs unit tests for a single, specified package. This is useful for focusing testing efforts on a particular area of the codebase.

```bash
cd packages/package-to-test
pnpm test
```

--------------------------------

### Run HTTP Tests with Makefile

Source: https://github.com/nexis-ai/nexis-appchain/blob/main/op-e2e/README.md

This command demonstrates how to run specific end-to-end tests using the Makefile. The 'make test-http' command initiates tests that likely involve HTTP communication or services.

```bash
make test-http
```