Your signing party, on your infrastructure

The client share on machines you control — deployed by you

The server co-signer is a binary you deploy: Docker Compose or Helm, with PostgreSQL, SQLite or cloud-object storage for the share. It joins MPC ceremonies automatically as your mandatory third party — high-throughput signing where the client share never leaves your perimeter.

Share the Trust, Guard the Keys

Create accountLive on testnet in an afternoon

Compare PlansIncluded in a plan, not an add-on

The problem

A phone is the wrong signer for a 3 a.m. settlement run

Mobile co-signing is right for human authorisation and wrong for continuous operations. The server co-signer is the same client party as a binary you run: your own cloud, your own network, your own key share — participating in every signing ceremony without waiting for someone to wake up.

Your perimeter, your shareThe client key share lives on infrastructure you control. Vaultody's two nodes still cannot reach quorum without it.
Deployed the way you deploy thingsA container image or a Helm release, monitored and patched by your team like any other internal service.
Continuity without concessionAutomated flows sign around the clock and remain bounded by the same policy your people operate under.

How it works

Deployment reality

Runs wherever you run: your cloud, your Kubernetes, your compliance zone. Share persistence is your choice, and the process auto-joins signing sessions over authenticated channels once deployed.

✓Docker Compose or Kubernetes/Helm
✓Persistence: PostgreSQL, SQLite, GCS or S3
✓Available on Business and Enterprise; the pattern IS the v2 non-custodial model

deploy

$ helm install mpc-cosigner vaultody/cosigner \ --set persistence=postgres ✓ share generated in your cluster ✓ auto-joining signing sessions # your share, your machines, your rules

Specification

Deployment specification

What it takes to run your own signing party.

ModelA client-operated MPC node joining the committee as the mandatory client party — 3-of-3 with you inside it.

RuntimeRuns wherever you run workloads: your cloud, your Kubernetes, or a self-managed host.

PrerequisiteYour MPC authentication material must be configured before a vault can be created with a server co-signing scheme.

CombinationRun it alongside the mobile co-signer when you want automation for routine flows and human approval above a threshold.

AvailabilityOne server co-signing key on Standard and Business, negotiated on Enterprise. Entry runs the mobile co-signer instead.

Plan changesCo-signing key allowances are checked when you downgrade, so a plan change cannot silently strand a deployed node.

Failure modeIf your node is unreachable, signing stops. That is the non-custodial guarantee, so run it like a production dependency.

RecoveryReshare moves your party to new infrastructure without changing a single address.

Frequently asked questions

Get answers to commonly asked questions.

How is this different from API signing?

Same idea, different residence: this is the co-signer binary on your infrastructure with the share in your persistence layer — maximum control, slightly more ops.

What if our server is compromised?

The attacker gets one share of three — not a key. Reshare rotates it out; policies bound what it could ever have signed.

Does it fit an air-gapped or VPC design?

VPC yes — scoped with Enterprise deployment. It needs connectivity to join signing sessions, so fully air-gapped operation is not the model.