Onboarding

From declarations to publication

Start with the provider quickstart to install mppi, create the private setup folder, log in to Circle, choose separate operator/recipient wallets and edit the declarations. Run the following commands from that folder with the same operator address and RPC environment.

• Provider setup from the beginning→

mppi provider onboard --testnet --wallet YOUR_OPERATOR_WALLET \
  --declarations provider-declarations.toml --rpc-env ARC_RPC_URL_TESTNET

Onboarding registers and publishes your provider. A completed setup still needs your running inference integration and public endpoint before it can serve paid work.

Provider declarations

Run mppi provider init --testnet in your private setup folder. Edit its provider-declarations.toml using this guide; onboarding produces the separate confirmed mppi.toml.

Replace every REPLACE value and review the illustrative numbers and capabilities. Do not add an identity ID manually. An upstream URL describes your engine; your application still connects its execution and token reporting.

• Return to provider setup→

Prepare the payout recipient

The recipient owner needs a wallet that can approve EIP-712 typed data on the selected Arc network. Keep its signing access on their own machine or custody system. The operator's Circle account stays on the serving side.

For a new Circle recipient, the owner follows Circle's account/login and funding steps on their own machine with a separate account. A Circle smart contract wallet is deployed on its first outbound transaction; creating it or receiving faucet funds is not enough.

Before exporting the short-lived MPPI proof, the owner should follow Circle's transfer guide to send a chosen amount of testnet USDC to another address they control on Arc testnet. Use ARC-TESTNET for this walkthrough and wait for a confirmed transaction. If the result is uncertain, retain its transaction reference and resolve it with Circle before sending again.

• Circle account and funding setup↗
• Circle transfer walkthrough↗
• Circle account deployment↗

For mainnet, perform recipient preparation on ARC with a deliberate amount of real USDC. An existing deployed recipient skips this activation step. EOA recipients use their wallet's own EIP-712 signing procedure; they do not need contract deployment.

Confirm the payout recipient

On first setup, use --provider-id YOUR_PROVIDER_ID to adopt an owned identity; without that flag or saved configuration, onboarding registers a new one. Retain the same adoption flag on proof-import and pending-operation reruns. The operator is always the same YOUR_OPERATOR_WALLET.

EIP-712 is a structured message your recipient wallet signs to approve its binding to this provider identity. Prepare the recipient's signing interface before exporting: the request has a five-minute onchain validity window. The recipient must support the registry's EOA or ERC-1271 signature check; a contract wallet must already be deployed on the selected network.

Export. Run onboarding and save its JSON output. Replace YOUR_OPERATOR_WALLET with the address selected in the quickstart. If adopting an identity, keep --provider-id YOUR_PROVIDER_ID on this command too:

mppi provider onboard --testnet --wallet YOUR_OPERATOR_WALLET \
  --declarations provider-declarations.toml --rpc-env ARC_RPC_URL_TESTNET > onboarding-result.json

Open onboarding-result.json in your editor. Only proceed when recipient_proof_required is true. Copy the complete value of its request field into a new recipient-request.json: include types, primaryType, domain and message, but not the outer onboarding-result object. Preserve every field and numeric digit. If the result is pending instead, rerun the same onboarding command to reconcile it first.

Review. Give recipient-request.json to the recipient owner through your established handoff channel. They should verify the following against your intended setup before approving:

• Registry addresses by network→

Sign. Use the recipient wallet's EIP-712 signing interface. For an existing Circle recipient ready on Arc testnet, its owner can use the commands below on their own machine, with Circle CLI installed. They log in to the recipient's separate account and enter the email code themselves. Replace the email and address with that recipient's values:

circle wallet login [email protected] --testnet

After the login succeeds, list the recipient account's wallets:

circle wallet list --type agent --chain ARC-TESTNET

Check that the selected address equals message.newWallet. Use it as YOUR_RECIPIENT_WALLET below. Run the signing command in the folder containing the reviewed recipient-request.json:

circle wallet sign typed-data "$(cat recipient-request.json)" \
  --address YOUR_RECIPIENT_WALLET --chain ARC-TESTNET --quiet \
  > recipient-signature.txt

The signing command must succeed and return a 0x signature. Send the signature file back to the operator; keep the recipient's login credentials on the recipient's machine. Other wallet products need their own EIP-712 signing procedure.

• Circle installation and email login↗
• Circle typed-data signing command↗
• ERC-8004 wallet verification↗

Assemble. Back in the operator's private setup folder, keep the original recipient-request.json and returned recipient-signature.txt. Save this helper as assemble-proof.mjs. It wraps the original request text without converting its integer fields:

import { readFileSync, writeFileSync } from "node:fs";

const request = readFileSync("recipient-request.json", "utf8").trim();
JSON.parse(request); // Check JSON syntax; retain the original text below.
const signature = readFileSync("recipient-signature.txt", "utf8").trim();
if (!/^0x(?:[0-9a-fA-F]{2})+$/.test(signature)) {
    throw new Error("Expected the recipient's hex signature.");
}
writeFileSync(
    "signed-recipient-proof.json",
    '{"request":' + request + ',"signature":' + JSON.stringify(signature) + '}\n',
    { flag: "wx", mode: 0o600 },
);

node assemble-proof.mjs

The helper creates signed-recipient-proof.json and refuses to overwrite an existing file. Import the proof with the same operator, declarations, network and any identity-adoption flag:

mppi provider onboard --testnet --wallet YOUR_OPERATOR_WALLET --declarations provider-declarations.toml \
  --rpc-env ARC_RPC_URL_TESTNET --recipient-proof signed-recipient-proof.json

Wait for complete: true before using the resulting mppi.toml. If an unsubmitted proof expires, keep the old files under distinct names and rerun without --recipient-proof to export a fresh request. Repeat review, signing and assembly for that request. If submission is already pending or unknown, preserve and reconcile the original operation first.

Publish the catalogue last

1. Validate declarations, network, trusted deployment and the authenticated operator.
2. Register or verify the provider identity and intended service URI.
3. Confirm the exact recipient binding and URI.
4. Publish the canonical model catalogue only after the preceding evidence is confirmed.

A completed rerun verifies the existing setup without registering again. Identity ID zero is valid. Conflicting retained state stops progress rather than silently switching operator or registration. Deliberate changes to completed setup use mppi provider update.

Results and retained records

Keep all records private, durable and backed up. They are not runtime token history or a database. Independent provider hosts still need coordination. If a wallet submission loses its result before its transaction ID is saved, it remains unknown; similar wallet history cannot identify it safely.

Install the Linux ARM64 CLI

This is the prebuilt alternative to the quickstart's source installation. Run it from your private setup folder on Linux ARM64. The checksum must report mppi-linux-arm64: OK before installation; mppi --version should report 0.2.0.

(set -eu
curl -fL -o mppi-linux-arm64 \
  https://github.com/Alethieum/mppi/releases/download/provider-v0.2.0/mppi-linux-arm64
curl -fL -o SHA256SUMS \
  https://github.com/Alethieum/mppi/releases/download/provider-v0.2.0/SHA256SUMS
sha256sum --check --ignore-missing SHA256SUMS
mkdir -p "$HOME/.local/bin"
install -m 755 mppi-linux-arm64 "$HOME/.local/bin/mppi"
export PATH="$HOME/.local/bin:$PATH"
mppi --version)
export PATH="$HOME/.local/bin:$PATH"

This release's binary verification covers Linux ARM64. Source installations on other platforms require their own successful build.

• Return to setup→

Use mainnet deliberately

Create a new private folder outside version control. Use the CLI installed in the quickstart, then log in with your actual operator email, enter its OTP yourself and select the wallet returned for ARC:

mkdir -m 700 mppi-provider-mainnet
cd mppi-provider-mainnet
circle wallet login [email protected]

After the mainnet login succeeds, list its wallets and initialize the declarations:

circle wallet list --type agent --chain ARC
export ARC_RPC_URL_MAINNET=https://rpc.blockdaemon.mainnet.arc.io
mppi provider init --mainnet

Edit the new provider-declarations.toml using this page's declarations field guide. Supply your mainnet origin, model prices and a separate recipient ready on Arc mainnet. Replace YOUR_MAINNET_OPERATOR with the selected ARC address. To adopt an existing mainnet identity, include its --provider-id on initial and continuation commands.

mppi provider onboard --mainnet --wallet YOUR_MAINNET_OPERATOR \
  --declarations provider-declarations.toml --rpc-env ARC_RPC_URL_MAINNET

Follow the recipient-proof process above using the exported mainnet request. The recipient signs on ARC, and every continuation uses --mainnet and ARC_RPC_URL_MAINNET. Keep this folder's complete records separate from testnet. Mainnet operations use real assets.

Your Python host must load this mppi.toml with testnet=False and rpc_env="ARC_RPC_URL_MAINNET", along with its real coverage/execution callbacks. Rust hosts retain the validated mainnet configuration. Verify the running endpoint with mppi provider verify --mainnet --rpc-env ARC_RPC_URL_MAINNET from this folder.

• Mainnet and testnet contracts→