3. Deploying to Stokenet and Mainnet

Overview

Once you have tested locally with resim, the next step is putting the package on a live network. Deployment is a transaction: you upload the compiled package to a web console, it builds a transaction manifest for you, and your wallet signs it and pays the fee.

Which network you can do that on has changed. The hosted console covers Mainnet; the Stokenet console was retired during 2026 and nothing replaced it, so deploying to the testnet now means running a console yourself. Both paths are below.

1. Get Test XRD

Skip this if you are deploying straight to Mainnet, where you pay fees in real XRD.

Stokenet has a faucet that hands out free test XRD, reached from the wallet itself. Add the Stokenet gateway first (Settings > App Settings > Gateways; the URL and the developer-mode step are on the Stokenet page), create an account on it, then per the official example walkthrough: tap the account name, the three dots, Dev Preferences, then Get XRD Test Tokens.

2. Build Your Package

scrypto build

Your compiled WASM file is at:

target/wasm32-unknown-unknown/release/<package_name>.wasm

The build also generates an RPD (Radix Package Definition) file at the same location, which describes your blueprints and their interfaces.

Where the Developer Console lives now

The Developer Console is no longer served by Radix. Checked with a browser user agent on 14 August 2026, console.radixdlt.com answers HTTP 302 to console.radixscan.io and preserves the path, so /deploy-package and /transaction-manifest both arrive at the same route on the new host. The page that loads is titled RadixScan Developer Console. dashboard.radixdlt.com redirects the same way.

That is deliberate rather than a lapsed domain: the redirects are issued from Radix's own edge, and the Foundation's operational-stack post of 26 January 2026 lists the Developer Console, Dashboard and Sandbox as P3 items – the tier it described as "prime opportunities for community teams" to take over. RadixScan, the team now hosting them, runs deployments of the same open-source dApps monorepo the originals were built from.

Nothing you click is broken, but the tool you are handing a package to is a community deployment. Nothing about the flow below changes; the hostname in your address bar does.

3. Deploy via the Developer Console

This deploys to Mainnet. The hosted console has no network selector – the network is fixed when the instance is built (see Deploying to Stokenet below).

1. Open console.radixscan.io/deploy-package.
2. Click Connect and connect your Radix Wallet, sharing the account that will pay the fee.
3. Upload both files: the .wasm and the .rpd.
4. Set Owner role and Owner role updatable. These decide who may later change package metadata and royalties; the official example selects None for both, which is the right choice only if the package needs no owner-gated behaviour. This is the owner of the package, not of the components instantiated from it.
5. Review the generated manifest, click Send to the Radix Wallet, and approve in the wallet.

Once the transaction commits, the console displays your package address. Save it – you need it to instantiate components.

Deploying to Stokenet: no hosted console

There is no hosted Stokenet Developer Console. Checked 14 August 2026: stokenet-console.radixdlt.com returns HTTP 530 from the Cloudflare edge with no origin behind it, on /deploy-package and /transaction-manifest alike, and no stokenet- hostname resolves under radixscan.io.

Radix's own documentation has not caught up. The step-by-step learning path hands its Stokenet section off to the official-examples repository, whose instructions still open with "Go to the Stokenet Developer Console Website" pointing at that 530 host. A developer following the documentation as written cannot complete the first deployment to a real network.

The working substitute is to run the console yourself from radixdlt/dapps-monorepo (Apache-2.0). The network is read from PUBLIC_NETWORK_NAME at build time, which is why one deployment serves one network:

git clone https://github.com/radixdlt/dapps-monorepo.git
cd dapps-monorepo
# .env: PUBLIC_NETWORK_NAME=stokenet
#       PUBLIC_DAPP_DEFINITION_ADDRESS=<your Stokenet dApp definition>
npx turbo run build --filter=console
node apps/console/build

It serves on port 3000, with the Gateway endpoints already carried in the repository, so you do not need a node of your own. The dApp definition address is yours to create first – see dApp Definition and Wallet Verification. Leaving it empty falls back to Radix's addresses, which the README warns will cause errors. apps/console can also go on Vercel by swapping @sveltejs/adapter-node for the Vercel adapter.

Stokenet itself is unaffected: the network runs, and its Gateway still answers at babylon-stokenet-gateway.radixdlt.com. It is the hosted web tooling that is gone.

After the reset – what you re-run

Stokenet is wiped on Saturday 29 August 2026. The date was set on 18 August 2026 by the network’s community operator and relayed to the Radix Developer Discussion group; the network goes down at 07:00 UTC (09:00 CEST) and several hours of downtime are expected, because the operator is taking the window for server maintenance as well. The ledger being replaced is not small: the Stokenet Gateway reported state version 425,013,339 at epoch 254,946 on 19 August 2026, running node v1.10.6. A developer whose launch plan the date breaks can say so in that group and ask for it to move.

What survives is what is derived rather than stored. Network ID 2, the Gateway URL, the well-known addresses (test XRD, the faucet, the native packages) and your own account addresses are all unchanged, so nothing in a client config or in a console instance built as above needs editing. What it points at is an empty ledger. Taking the steps on this page in order, that means:

1. Step 1, test XRD – balances are gone; re-fund the same account from the faucet.
2. Step 2, build – unaffected. The .wasm and .rpd are local artefacts.
3. Step 3, publish – every package is destroyed; re-publish, and expect a new package address. Anything that hard-codes the old one (a front end, a manifest, a test fixture) has to be updated.
4. Step 4, instantiate – components go with their packages; re-instantiate and record the new component address.

Two things outside this page’s steps also go: on-ledger persona data, so wallet personas are recreated, and dApp Definition metadata, so a verified dApp stops verifying until its metadata is re-populated. The operator intends to repeat the exercise every 9–12 months, so a Stokenet deployment is best treated as disposable by default. Full terms: Stokenet.

4. Instantiate a Component

Go to the Send Raw Transaction section of the console and submit a manifest that calls your instantiation function:

CALL_FUNCTION
  Address("<PACKAGE_ADDRESS>")
  "GumballMachine"
  "instantiate"
  Decimal("5")
;
 
CALL_METHOD
  Address("<YOUR_ACCOUNT>")
  "deposit_batch"
  Expression("ENTIRE_WORKTOP")
;

The resulting component address is your live dApp on Stokenet.

Next Steps

• Scrypto Fundamentals – understand the asset-oriented programming model
• Radix dApp Toolkit – build a frontend that connects to your component
• Transaction Manifest Language – learn to write manifests directly

External Links

• RadixScan Developer Console – where console.radixdlt.com now lands
• Official example: publishing a package
• radixdlt/dapps-monorepo – source of the Console, Dashboard and Sandbox
• The Foundation Operational Stack: Mapping the 2026 Transition
• Official deployment guide
• What is Stokenet?