Deploying io.sign

io.sign is the core signing product in the io.finnet stack. It produces threshold signatures using Multi-Party Computation (MPC) and distributes key shares across signers, so no single party ever holds the full private key. Everything else in the stack depends on it: Treasury and Tokenisation in io.vault, and io.network build on top of the signatures io.sign produces.

A deployment has a coordinating backend and signers. Choose who operates the backend, then choose Mobile Signers, Virtual Signers, or both:

• The backend coordinates signing. It fetches requests waiting for approval and coordinates an eligible signer set once enough signers approve, producing a raw signature. It does not broadcast the transaction: you broadcast the signature yourself or hand it to io.vault. You can run the backend yourself, or let io.finnet run it for you.
• The signers hold key shares and take part in signing. People use Mobile Signers; automated workflows use Virtual Signers that you operate. You can combine both types in a vault.

This split matters because your key shares live on your signers, never on the backend. Letting io.finnet operate the backend does not put io.finnet in possession of a key share. The signing protocol is identical across every combination. What changes is who runs the backend and who carries its operational burden.

This page describes backend deployment models and hosting choices for Virtual Signers. If you are starting with mobile signing, follow Get started with io.sign. For the mechanics of deploying a Virtual Signer, follow the links to the Virtual Signer deployment guides.

Choosing a deployment model

Choose your signer types independently of who runs the backend. If you use Virtual Signers, you operate them yourself. The trade-off on the backend is control against operational effort. Running the backend yourself gives you full control over the signing coordination path. Letting us run it removes that operational work and leaves you to run your signers and configure signing policies.

If you use Virtual Signers, each runs either on premise on bare metal or in your own cloud account. Those options are covered below and apply regardless of who runs the backend.

In every model, io.sign signs the same way and returns the same raw signature. The signature is a standard ECDSA or EdDSA signature, verifiable by any blockchain node regardless of where it was produced.

Running your Virtual Signers

You run each Virtual Signer yourself. This holds in every model, because the key shares live on the signers you run. A Virtual Signer runs either on premise or in your own cloud account.

On premise

Run a Virtual Signer on bare metal Linux servers in your own data centre. This suits institutions with air-gapped environments or regulatory requirements that keep signing infrastructure inside their own perimeter.

Production deployments use AMD SEV-SNP hardware attestation, which encrypts memory at the hardware level and lets the platform verify that the signer is running unmodified code in a genuine secure enclave. For development and testing on hardware without SEV-SNP, simulated attestation is available, including on ARM64. Do not use simulated attestation in production.

You are responsible for the hardware, operating system patching, monitoring, and backups. In exchange, you control the full network path and the physical location of every key share.

See Deploy self-hosted for the deployment steps.

Your own cloud

Run a Virtual Signer in your own AWS or Azure account. This suits institutions that already operate in the cloud and want their signers to sit inside their existing account, IAM boundaries, and monitoring.

• AWS. The Virtual Signer runs within AMD SEV-SNP secure enclaves, with encrypted key material stored in S3. You generate a CloudFormation template scoped to your account and deploy it there. See Deploy on AWS.
• Azure. The Virtual Signer runs on Azure Confidential Computing, using Secure Key Release (SKR) for hardware-attested management of the encryption keys, with encrypted storage in Azure Blob Storage.

You manage the cloud account, IAM policies, monitoring, and backups. io.finnet provides the deployment artifacts and the signer image; you own the account they run in.

Choosing who runs the backend

The backend fetches requests waiting for approval and coordinates an eligible signer set once enough signers approve, producing a raw signature. It does not broadcast the transaction: you broadcast the signature yourself or hand it to io.vault. Your Mobile Signers and/or Virtual Signers connect to the backend to take part in signing. You can run this backend yourself or let io.finnet run it.

Self-hosted backend

Run the backend on your own infrastructure and connect your chosen signers. This gives you full control over the signing coordination path, at the cost of operating and monitoring the backend yourself. For the components, prerequisites, environment variables, and topology, see Configuring io.sign.

io.finnet-managed backend

Let io.finnet run the backend for you. This is the fastest path to production: you manage your chosen signers, and io.finnet operates the signing coordination infrastructure they connect to. If you use Virtual Signers, you operate their infrastructure.

Handing the backend to io.finnet does not hand over any key material. Your key shares stay on your Mobile Signers and/or Virtual Signers, and no single party, including io.finnet, ever holds a complete private key. You manage signing policies and signers through the Dashboard and the API.

What stays the same across models

The deployment model changes who runs the infrastructure. It does not change the security properties of signing:

• Key shares are generated in a distributed ceremony where no single party ever knows the complete private key.
• Signing requires participating signers whose combined signing weight meets the configured threshold; review Vaults, signers, and thresholds when assigning weights.
• io.sign returns a raw signature. You can broadcast it yourself or use io.vault to broadcast it automatically.
• Disaster recovery runs the same way. Signers pool their key shares using the offline, open-source recovery tool, independent of where io.sign was deployed.

For the details of how a signature is produced, see How io.sign Signs Transactions. For the disaster recovery process, see Disaster recovery process.