Institutional Signing (S3C)
S3C (Self-Custodial Smart Contracts) lets an institution run the signing of its own vBTC vaults. The institution operates at least three VerifiedX validators and registers them as its signing pool. Every vault its node creates then has its key generated by, and held only by, those validators: the public validator set never holds a share, and every Bitcoin signature for the vault comes from the institution's own infrastructure.
Nothing else about the vault changes. Consensus still verifies the vault's Bitcoin deposits and spends from Bitcoin's own proof-of-work and Merkle proofs, and still fixes the exact Bitcoin transaction that pays each withdrawal before it is signed. The institution controls authorization and execution; the network's rules still decide what may be executed. See Bitcoin Integration and vBTC.
How it works
- The pool. The node that creates the vaults (the minting node) lists the pool's validators in its configuration. Its key ceremonies use exactly those validators and no others.
- All or nothing. Every validator in the pool must be usable, and all of them take part in the key ceremony. If any one is not, the ceremony fails and names it. If the pool configuration is invalid, the node refuses to create vaults at all rather than fall back to the public validator set.
- Threshold. A withdrawal needs signatures from 51% of the pool, rounded up: 2 of 3, 3 of 4, 3 of 5.
- Withdrawals. When a withdrawal is requested, consensus fixes the Bitcoin transaction that pays it, in the same block. The pool's validators sign exactly that transaction and broadcast it. They cannot sign anything else for the vault.
- Separation. S3C validators take no part in public vaults' key ceremonies or key rotations. Like every aged validator they still sign the Bitcoin reports that record vault events for the whole network.
- Keys stay with the pool. The chain never moves an S3C vault to a new key. Keeping enough of the pool healthy is the institution's responsibility (see Plan for redundancy).
What you need
- At least three validators, each set up as in Run a Validator: its own server with a static public IPv4 address (IPv6 addresses and host names are not accepted in the pool), the validator ports open, and its own address holding 5,000 VFX bonded.
- Two days of bond age. A validator joins a key ceremony only once its bond has been in place for 14,400 blocks (about two days).
- A minting node: the node that holds the vault owner's address and creates the vaults, with its wallet API enabled. It must be able to reach every pool validator at the addresses you list.
1. Flag each validator as S3C
On each pool validator, add this line to config.txt (~/.local/share/RBX/Config/config.txt on Linux mainnet):
S3CValidator=true
Keys are case-sensitive, and the node stops reading config.txt at the first blank line, so put the line in the uninterrupted block of settings at the top.
Restart the node and start validating (step 9 of the validator guide). The validator's registration and every heartbeat it sends now carry the S3C flag on chain. The flag follows the latest of those transactions, so keep S3CValidator=true in place: a heartbeat sent without it turns the validator back into a public one.
2. Configure the minting node
On the minting node, list the pool in config.txt, one IP:ValidatorAddress entry per validator, separated by commas:
S3C=203.0.113.10:xVALIDATOR_ADDRESS_1,203.0.113.11:xVALIDATOR_ADDRESS_2,203.0.113.12:xVALIDATOR_ADDRESS_3
The node checks the list when it starts: at least three entries, public IPv4 addresses only, valid VFX addresses. From then on, every vault this node creates is an S3C vault on this pool.
Restart the node, then check the pool before creating anything:
curl -s -H "apitoken: YOUR_API_TOKEN" http://localhost:7292/vbtcapi/VBTC/GetS3CStatus
It returns Enabled, ConfigInvalid and IsS3CValidator, and for each configured validator RegisteredOnChain, Reachable and ConfigIPMismatch. Every validator should be registered and reachable before you create a vault.
3. Create a vault
S3C vaults are created through the node API, in the same three steps as any vault:
POST /vbtcapi/VBTC/InitiateMPCCeremony/{ownerAddress}starts the key ceremony on the pool.GET /vbtcapi/VBTC/GetCeremonyStatus/{ceremonyId}follows it until it completes.POST /vbtcapi/VBTC/CreateVBTCContractcreates the vault, and its Bitcoin deposit address follows.
See Creating a vault for each request and response. The raw creation routes used by the web wallet always use the public validator set, so S3C vaults must be created through these node routes.
From here the vault works like any other: deposits are credited once buried under 6 Bitcoin blocks, vBTC transfers freely, and withdrawals follow the watched-vault flow.
Operating the pool
- Keep the validators validating. A pool validator signs withdrawals only while its node is validating. A validator that drops out of validating (for example after failing its port check) signs nothing until it is started again.
- Keep registered IPs current. The key ceremony contacts each validator at the IP in the minting node's
S3C=line, but withdrawal signing finds each validator at the IP registered on chain. If a validator moves, update both. - Exiting a validator does not remove its share. A pool validator that exits still holds key shares of the pool's vaults. Keep its node and key shares until those vaults are emptied: their withdrawals still need it. Key backups are shared only among the vault's own pool.
- Moving vBTC to Base. vBTC cannot be bridged to Base directly from an S3C vault.
POST /vbtcapi/VBTC/StartS3CAutoBridge(S3CContractUID,RequesterAddress,Amount,EvmDestination) withdraws the amount to a public companion vault and bridges it from there in one orchestration; follow it withGET /vbtcapi/VBTC/GetS3CAutoBridgeStatus/{orchestrationId}. Its progress is held in memory, so after a node restart finish the remaining steps by hand.
Plan for redundancy
Because the chain never re-keys an S3C vault, the pool must keep enough healthy validators to sign. If fewer healthy holders remain than the threshold, new withdrawal requests on the vault are refused until enough of them are back.
| Pool size | Signatures needed | Validators that can be lost |
|---|---|---|
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
A pool of five tolerates two validators down at once. Spread pool validators across hosts and locations so a single outage cannot take out enough of them.