Registration & Bonding

This page shows the on-chain steps that make a ciphernode an active operator. It is for operators who installed the node as shown on Run a Ciphernode. You authorize a bond owner, bond FOLD, register the operator, and buy tickets. At the end, interfold ciphernode status shows Active: true.

Operator key and bond owner

An operator position uses two roles. They can be the same wallet, but a separate cold wallet or Safe as the bond owner is recommended. Then the node never holds the key that controls the collateral.

• The operator key is the key that the node loads. It is the identity in the registry, holds the tFOLD ticket balance, submits sortition tickets, and signs DKG proofs. Bans and slashes apply to it. It calls setBondOwner one time.
• The bond owner is the wallet or Safe that holds FOLD and the ticket collateral. It sends every collateral and registration call (the ...For(operator) functions). Exit payouts go to the bond owner. The registry also sends rewards to the bond owner, or to the operator when no owner is set.

One bond owner can fund several operator keys. totalBonded(owner) returns the active and pending FOLD of that owner across all its operators. A committee takes at most one operator from each bond owner (see Committee limits).

A call from the wrong wallet reverts with NotBondOwner(caller, operator).

Before you start

Make sure that you have these items:

• A node configuration with the operator key stored in it. See Run a Ciphernode. The node must run before the operator can become active, because the node acknowledges its release on-chain when it starts. The operator key needs ETH for that transaction and for ticket submissions.
• A bond owner that holds at least requiredCiphernodeBond FOLD, the ticket collateral for at least minTicketBalance tickets, and ETH for gas. See Economic parameters.
• For a bond owner that is an EOA: a second configuration file whose stored wallet is the bond owner key. Copy the node configuration into another directory, then run interfold password set and interfold wallet set with --config for that file. The key store is created next to that file, apart from the node keys. This page calls the file owner.yaml.

For a Safe bond owner, send the same BondingRegistry calls through the Safe. Before bondCiphernodeFor, approve FOLD for the BondingRegistry. Before addTicketBalanceFor, approve the ticket collateral for the InterfoldTicketToken contract, not for the BondingRegistry. Safe amounts are in token base units.

Read the token addresses

The CLI reads the token addresses from the BondingRegistry, so you do not need them for the CLI steps. A Safe or a wallet needs them for the approvals. Read them with Foundry cast. Take the BondingRegistry address from Contract addresses.

BONDING=<BondingRegistry address>
RPC=https://your-endpoint.example
 
# FOLD, the bond token
cast call "$BONDING" "getCiphernodeBondToken()(address)" --rpc-url "$RPC"
 
# InterfoldTicketToken (tFOLD), the spender for the collateral approval
TICKET=$(cast call "$BONDING" "getTicketToken()(address)" --rpc-url "$RPC")
echo "$TICKET"
 
# The ticket collateral token that tFOLD wraps (sUSDS on mainnet)
cast call "$TICKET" "underlying()(address)" --rpc-url "$RPC"

Register the operator

1. AuthorizeThe operator key sets the bond owner.
3. BondThe bond owner bonds FOLD.
5. RegisterThe bond owner registers the operator.
7. TicketsThe bond owner deposits ticket collateral.
9. ActiveThe registry marks the operator active.

The order is fixed. registerOperatorFor needs the full bond, so the bond comes first. addTicketBalanceFor reverts with NotRegistered() before registration, so tickets come last.

interfold ciphernode status

Ciphernode status on mainnet:
  Operator key: 0xOPERATOR
  Bond owner: not configured
  Registered: false
  Active: false
  Exit pending: false
  Ticket balance: 0 (0 available)
  Ciphernode bond: 0
  Pending exits: tickets=0, bond=0
  Requirements: minTickets=1, ticketPrice=1000 tFOLD, ciphernodeBond=32000 FOLD
  Committees: none

interfold ciphernode set-bond-owner --owner 0xBOND_OWNER

interfold --config /path/to/owner.yaml ciphernode bond \
  --operator 0xOPERATOR bond --amount 32000

interfold --config /path/to/owner.yaml ciphernode register --operator 0xOPERATOR

interfold --config /path/to/owner.yaml ciphernode tickets \
  --operator 0xOPERATOR buy --amount 1000

interfold ciphernode status --operator 0xOPERATOR

Ciphernode status on mainnet:
  Operator key: 0xOPERATOR
  Bond owner: 0xBOND_OWNER
  Registered: true
  Active: true
  Exit pending: false
  Ticket balance: 1000 (1 available)
  Ciphernode bond: 32000
  Pending exits: tickets=0, bond=0
  Requirements: minTickets=1, ticketPrice=1000 tFOLD, ciphernodeBond=32000 FOLD
  Committees: none

The available tickets are floor(ticket balance / ticketPrice). With a ticket price of 1,000 sUSDS shares, a deposit of 1,000 sUSDS shares gives one ticket, and 1,999 shares still give one ticket.

For a self-owned position, use one configuration for all steps. Set the owner to your own address, and omit --operator: the CLI then uses the address of the configured signer.

CLI commands

All commands below accept --chain <name>. It selects the chain entry by its name. Without it, the CLI uses the first entry in chains. For bond and tickets, put --operator and --chain before the inner command (bond, unbond, claim, buy, or burn). The CLI Reference lists every flag.

Activate and deactivate

activate sends refreshOperatorStatus for a registered operator. The contract recomputes the active status from the registration, the release acknowledgment, bans, the bond and the tickets. Use it after a requirement changed or after the release was acknowledged from another process. activate does not register: for an operator that is not registered it stops and points to register. To register an operator again after a full exit, use register.

deactivate needs --tickets, --bond, or both. It calls removeTicketBalanceFor for the ticket amount and unbondCiphernodeFor for the bond amount. --tickets is a tFOLD amount, not a ticket count. The operator stays registered. For a full exit, use deregister, as shown on Exits, Rewards & Slashing.

interfold --config /path/to/owner.yaml ciphernode deactivate \
  --operator 0xOPERATOR --tickets 1000 --bond 32000

Change the bond owner

The current bond owner proposes a new owner. The new owner then accepts:

interfold --config /path/to/current-owner.yaml ciphernode propose-bond-owner \
  --operator 0xOPERATOR --new-owner 0xNEW_OWNER
interfold --config /path/to/new-owner.yaml ciphernode accept-bond-owner \
  --operator 0xOPERATOR

The acceptance moves the ownership of the active and pending FOLD of the position to the new owner in one transaction. The FOLD stays in the BondingRegistry. The operator key does not take part. The acceptance reverts with BondOwnerTransferViolatesLock when the move leaves the old owner with less wallet-plus-bonded FOLD than its locked FOLD balance. A change of owner starts the admission cooldown again.

Activation rules

The BondingRegistry marks an operator active only when all of these conditions are true:

• The operator is registered.
• No authorized slashing manager has banned the operator.
• The bond is at least ceil(requiredCiphernodeBond × ciphernodeBondActiveBps / 10,000).
• floor(ticket balance / ticketPrice) is at least minTicketBalance.
• The acknowledged node release matches the required protocol version, and its node generation is at least the required generation (isNodeReleaseReady).

ciphernodeBondActiveBps is 8,000 (80%) after initialization. On mainnet, an operator therefore stays active with at least 25,600 FOLD.

Registration and active status use different bond thresholds. registerOperatorFor needs the full requiredCiphernodeBond. isCiphernodeBonded tests only the 80% floor. An operator between the two reads as bonded, but registration reverts with NotCiphernodeBonded(). To test registration, compare getCiphernodeBond(operator) with requiredCiphernodeBond().

Refresh a cached status

Governance can change ticketPrice, requiredCiphernodeBond, ciphernodeBondActiveBps, and minTicketBalance. Each change makes every cached status read as inactive until a refresh. Anyone can refresh a registered operator:

cast send "$BONDING" "refreshOperatorStatus(address)" 0xOPERATOR \
  --rpc-url "$RPC" --interactive

--interactive makes cast ask for the private key of any wallet that can pay the gas.

The call reverts with NotRegistered() for an operator that is not registered. refreshOperatorStatuses(address[]) refreshes a batch, and it reverts when one operator in the list is not registered. ciphernode activate refreshes one operator; the CLI has no command for a batch. A node start also refreshes a registered operator that is not active, because its release acknowledgment calls refreshOperatorStatus.

Committee limits for each bond owner

Sortition counts bond owners, not operator keys. For each new E3 request:

• A committee takes at most one operator from each bond owner. The owner is the owner at the timestamp before the request (bondOwnerAt(operator, requestBlock - 1)). When two operators of one owner submit tickets, the better score replaces the other.
• The request reverts with InsufficientBondOwners when the counted active bond owners are fewer than the committee size N.

Extra operator keys under one bond owner therefore do not give more committee seats in one E3. Tickets & Sortition explains the scores.

Admission cooldown

The BondingRegistry owner can set an admission policy with setAdmissionPolicy(cooldownEnabled, cooldownDuration, admissionsPaused). When the cooldown is on, a new registration or a bond owner change must wait cooldownDuration seconds before the position counts for new committees. Funding tickets later does not restart the wait. When admissions are paused, positions that were not eligible before the pause cannot enter. An unset policy has no cooldown.

Read the current policy:

cast call "$BONDING" \
  "admissionPolicyAt(uint256)((bool,bool,uint48,uint48,bool,uint48))" "$(date +%s)" \
  --rpc-url "$RPC"

The first three values are cooldownEnabled, admissionsPaused, and cooldownDuration. On 25 September 2026, mainnet returned (true, false, 259200, 0, false, 0): a cooldown of 3 days.

Economic parameters

The values below are from the mainnet deployment configuration (packages/interfold-contracts/deploy/protocol/mainnet-protocol.config.json). On 25 September 2026, the on-chain values were the same. Governance can change them, so read them on-chain before you deposit. Sepolia uses the same values, except for ticketPrice and requiredCiphernodeBond. The Sepolia ticketPrice is 1 USDC (1,000,000 base units), and the Sepolia requiredCiphernodeBond is 100 FOLD. The Sepolia ticket collateral is MockUSDC.

The contract limits exitDelay to between 1 day and 90 days. Read the values with cast:

cast call "$BONDING" "requiredCiphernodeBond()(uint256)" --rpc-url "$RPC"
cast call "$BONDING" "ciphernodeBondActiveBps()(uint256)" --rpc-url "$RPC"
cast call "$BONDING" "ticketPrice()(uint256)" --rpc-url "$RPC"
cast call "$BONDING" "minTicketBalance()(uint256)" --rpc-url "$RPC"
cast call "$BONDING" "exitDelay()(uint64)" --rpc-url "$RPC"

requiredCiphernodeBond is in token base units (18 decimals). ticketPrice is in base units of the ticket collateral (18 decimals on mainnet, 6 decimals for USDC on Sepolia).

Good practice

• Keep the bond above the 80% floor with a margin, so that a slash does not make the operator inactive.
• Keep more than minTicketBalance tickets, so that a ticket slash does not make the operator inactive.
• Watch for OperatorActivationChanged events for your operator. The registry emits one each time the active status changes.
• Watch for SlashProposed events for your operator, and for isActive changes to false.

Troubleshooting

Next steps