Handing it over

• 1

  Send the config

  The ZIP Defender exported (the Defender migration guide covers the rest of the move), or monitors/, triggers/, networks/ and config.json written by hand. Secret references stay references; the values come separately, as described under Secret values below.

• 2

  Grant the key

  The relayer signs through your own provider, and you grant one credential for one key:

  Provider	Grant
  AWS KMS	kms:GetPublicKey and kms:Sign on one key ARN, key spec ECC_SECG_P256K1. Policy.
  Google Cloud KMS	roles/cloudkms.signerVerifier (or roles/cloudkms.signer plus roles/cloudkms.publicKeyViewer) bound on one HSM secp256k1 key, through a service-account key (1.8.0 has no workload identity, #757). The Viewer role is not enough: it lacks viewPublicKey, which the relayer needs at startup.
  Turnkey	A non-root API user with one ALLOW on ACTIVITY_TYPE_SIGN_TRANSACTION_V2 for one private key, pinned to your chain, contracts and functions, plus the zero-value self-sends the relayer uses to cancel and fill nonce gaps, and DENY rules for raw-payload signing and credential changes. The security page has the details.

  AWS KMS has been run end to end here, on a real key. The Google Cloud KMS and Turnkey grants above come from their documentation and the 1.8.0 source and have not been run here yet, so with either one the first step is a testnet run with your key.

  Each grant can be revoked from your own console at any time; the security page says which revocation to use for each provider.

• 3

  Nonceworks brings it up

  Monitor 1.6.0 and Relayer 1.8.0 from Docker Hub, unmodified and pinned by digest, in a Compose project of their own with a private network and their own Redis. The control plane runs the Monitor's own --check on your config before it starts and refuses a config that fails it. The relayer derives its address from your key at startup, and we send that address to you.

• 4

  You fund the address

  You send gas to the relayer address. From then on, upgrades and incidents are ours to handle, and each one gets a written note.

Secret values

RPC keys, webhook URLs, chat tokens and the provider credential come separately from the config, encrypted with age to this public key, which is also at nonceworks.com/age.txt:

age1engh35zk5tsch46n0q2uz09q0q38wr8ks099wehpljnjc7t953zspkjk3h

age -r $(curl -s https://nonceworks.com/age.txt) -a secrets.env > secrets.age

The same key is in the GitHub profile README of Zachary Alexander, who runs Nonceworks, so you can check one copy against the other before you use it. Send secrets.age on Telegram or by email, in a different message from the config. Once decrypted, credentials and tokens live only in two environment files in your workspace, one per container (files mode 0600), never in config.json. RPC URLs are the exception: Relayer 1.8.0 takes them only as plain strings in config.json, so give the relayer RPC keys with origin or IP limits. The Monitor gets only the values its configuration references; your provider credentials go to the Relayer alone.

Reaching the relayer API

Your app will call the relayer's API over HTTPS at https://api.nonceworks.com/t/<your team>/api/v1, with the relayer API key as a bearer token and a Cloudflare Access service token for your team. Creating relayers, signers, notifications, networks and API keys through the API is not available there, and the sign endpoints are off unless you ask for them. The gateway behind it is built and tested, and goes live with the first stack.

The files on our side

Three excerpts. The signer block is the only part we write; the trigger and monitor files are yours as exported.

config.json, signers[] (what we write for an AWS key)

{"id": "team-aws", "type": "aws_kms",
 "config": {"region": "us-east-1",
            "key_id": "arn:aws:kms:us-east-1:123456789012:key/1111-2222-3333"}}

triggers/slack.json (yours; the secret is a reference, and the value lives in the stack's environment)

{"team_slack": {"name": "Team Slack", "trigger_type": "slack",
  "config": {"slack_url": {"type": "environment", "value": "TEAM_SLACK_URL"},
             "message": {"title": "Large transfer",
                         "body": "${events.0.args.value} from ${events.0.args.from}"}}}}

monitors/usdc.json, match_conditions (yours)

"events": [{"signature": "Transfer(address,address,uint256)",
            "expression": "value > 10000000000"}]

Upgrades

Releases are staged against a copy of your configuration before your stack gets them. The operations page has the steps, and the 1.4 to 1.8 notes are an example of the write-up.

Leaving

You take the same files and run them anywhere; there is no Nonceworks format to convert from. The relayer keeps its transaction records and nonce counter in Redis; you can have a copy of that store with its storage key, which your relayer loads with one RESET_STORAGE_ON_START=true start so it picks up your config and your own credential; or start on a fresh Redis once pending transactions have settled. Then revoke the grant you gave us.

Limits of the relayer's policies

We never hold the signing key itself, and we never run a key we generated in place of yours. The relayer refuses transactions outside the policies set on it (whitelist_receivers, gas_price_cap, min_balance), except that it bumps its own no-op and cancel transactions past gas_price_cap. Those policies run on our host, the API key we generate for your stack can change them and we hold it as well as you, and the sign endpoints sit outside them. The security page covers what still holds if the host is compromised, and this note covers the sign endpoints.