Local → DevNet in one flag

The first two lessons ran against a validator on 127.0.0.1. This lesson shows that none of the gen CLI semantics change when you point at the shared DevNet — only the URL, an auth header, and ~100 ms of network. This is on purpose. There is no “local mode SDK” and “production SDK”. There is one CLI, one wire protocol, one gas model.

Prerequisites · DevNet access. Ask your Gen Labs contact for the RPC URL and a bearer token. Substitute the URL for <DEVNET_RPC_URL> in the examples below, and export the token as GEN_DEVNET_BEARER_TOKEN.

Steps

CLI
Rust SDK

Point at DevNet

export SERVER_URL="<DEVNET_RPC_URL>"
export GEN_DEVNET_BEARER_TOKEN="..."   # your token

From here on, every gen invocation will include the auth header. The cleanest way is to wrap it once:

gen_remote() {
  "$GEN" "$1" --rpc-url "$SERVER_URL" \
    --header "authorization=Bearer $GEN_DEVNET_BEARER_TOKEN" \
    "${@:2}"
}

Now gen_remote wallet --json show alice does on DevNet exactly what "$GEN" wallet --rpc-url "$SERVER_URL" --json show alice did locally.

Re-run lesson 1's identity check

gen_remote wallet --json show alice | jq -r '.result.account'

Same account address as on local. Identity is local-first — the key is yours and works against any RPC you can reach. The chain just doesn’t yet know about this address on DevNet (no activation has mentioned it there).

Faucet on DevNet

gen_remote wallet --json faucet \
  --wallet alice \
  --amount 1000000000 \
  --no-wait

Same command. Different network. Same Receipt envelope:

Receipt · 1 activation · 0.001¢ USDG · ~100 ms · Latency went up by network RTT; everything else is identical.

Verify on DevNet

gen_remote client --json balance --account "$ALICE"

Same JSON shape as on local.

Build a client pointed at DevNet

The local-vs-DevNet diff in Rust is exactly the constructor — one URL, one optional auth header.

use client_sdk::GenClient;
use gen_rpc_client::ClientConfig;
use std::collections::BTreeMap;

// Local — no auth.
let client = GenClient::new_json_rpc("http://127.0.0.1:30001")?;

// DevNet — same crate, same client type, just with auth.
let mut headers = BTreeMap::new();
headers.insert(
    "authorization".to_string(),
    format!("Bearer {}", std::env::var("GEN_DEVNET_BEARER_TOKEN")?),
);
let config = ClientConfig::builder()
    .server_url("<DEVNET_RPC_URL>".to_string())
    .headers(headers)
    .build();
let client = GenClient::new_json_rpc_with_rpc_config(config)?;

That client handle is what every Rust example in the rest of the curriculum uses.

Re-run lesson 1's identity check from Rust

use vm_primitives::gvm::GvmAccount;
use std::str::FromStr;

let alice = GvmAccount::from_str(&std::env::var("ALICE")?)?;
let resp = client.get_account(alice).await?;
println!("alice on devnet: {} components", resp.components.len());

Same key, same address — the chain just hasn’t seen activations from it yet on DevNet.

Faucet stays on the CLI

The SDK does not expose wallet faucet. Rust apps shell out to gen wallet faucet ... during setup, then resume using the SDK:

use std::process::Command;

Command::new("gen")
    .args(["--rpc-url", &std::env::var("SERVER_URL")?,
           "--header", &format!("authorization=Bearer {}",
                                std::env::var("GEN_DEVNET_BEARER_TOKEN")?),
           "wallet", "faucet", "--wallet", "alice",
           "--amount", "1000000000", "--no-wait"])
    .status()?;

Wrap this in a small bootstrap helper that creates the wallet (if needed), faucets it, and polls get_account until the token holder appears.

Verify the balance from Rust

let balance = client.get_balance(alice).await?;
println!("alice: {} subunits", balance.value());

Same JSON-RPC call as the CLI’s client balance, one async function.

The Rust crates are pinned in the demo at gen-rpc-client and gen-rpc-wire v0.13.0 from gen-bc/gen-framework-preview. Wallet creation and faucet are explicitly not in the SDK — they stay on the gen CLI (see lessons 1 and 2). The SDK covers everything from get-account / view / build-activation onward.

The whole local-vs-DevNet delta, in one table

Concern	Local	DevNet
Binary	`gen`	`gen` (same)
Wire protocol	JSON-RPC	JSON-RPC (same)
RPC URL	`http://127.0.0.1:30001`	`<DEVNET_RPC_URL>`
Auth	none	bearer token header
Block time	~100 ms	~100 ms
Activation cost	0.001¢ USDG	0.001¢ USDG
Round-trip latency	~10 ms	~100 ms

That’s it. Everything else — wallet semantics, account model, activation flow, contract deployment, view calls — is byte-for-byte the same.

What just happened

You proved that the CLI is network-agnostic: the same script you write against your laptop will run against DevNet, against the public testnet when it ships, and against mainnet, with no code changes — only the RPC URL. This matters more than it sounds. A common failure mode in other ecosystems is “works on Hardhat, breaks on mainnet” — code that depends on local-only behaviors. The Grid CLI is designed so that doesn’t happen.

What’s next

Transfer between accounts

The first activation you’ll build, sign, and submit yourself.

​Steps

​The whole local-vs-DevNet delta, in one table

​What just happened

​What’s next

Transfer between accounts

Steps

The whole local-vs-DevNet delta, in one table

What just happened

What’s next