Skip to content

Deployment and Operations

Jump to bottom
RunTimeAdmin edited this page Oct 30, 2026 · 23 revisions

Deployment & Operations

**Referenced Files in This Document** - [README.md](https://github.com/RunTimeAdmin/Sigvara/blob/main/README.md) - [deploy-testnet.md](https://github.com/RunTimeAdmin/Sigvara/blob/main/docs/deploy-testnet.md) - [oracle README.md](https://github.com/RunTimeAdmin/Sigvara/blob/main/oracle/README.md) - [docker-compose.oracle.yml](https://github.com/RunTimeAdmin/Sigvara/blob/main/docker-compose.oracle.yml) - [docker-compose.checker.yml](https://github.com/RunTimeAdmin/Sigvara/blob/main/docker-compose.checker.yml) - [docker-compose.watcher.yml](https://github.com/RunTimeAdmin/Sigvara/blob/main/docker-compose.watcher.yml) - [Deploy.s.sol](https://github.com/RunTimeAdmin/Sigvara/blob/main/script/Deploy.s.sol) - [Upgrade.s.sol](https://github.com/RunTimeAdmin/Sigvara/blob/main/script/Upgrade.s.sol) - [SplitAuthority.s.sol](https://github.com/RunTimeAdmin/Sigvara/blob/main/script/SplitAuthority.s.sol) - [docker-compose.mainnet.yml](https://github.com/RunTimeAdmin/Sigvara/blob/main/docker-compose.mainnet.yml) - [check-mainnet.sh](https://github.com/RunTimeAdmin/Sigvara/blob/main/scripts/check-mainnet.sh) - [check-role-holders.mjs](https://github.com/RunTimeAdmin/Sigvara/blob/main/scripts/check-role-holders.mjs) - [record-implementations.mjs](https://github.com/RunTimeAdmin/Sigvara/blob/main/scripts/record-implementations.mjs)

Table of Contents

  1. Introduction
  2. Project Structure
  3. Core Components
  4. Architecture Overview
  5. Detailed Component Analysis
  6. Dependency Analysis
  7. Performance Considerations
  8. Troubleshooting Guide
  9. Conclusion
  10. Appendices

Introduction

This document is the production deployment and operations guide for Sigvara’s protocol and Oracle service. It covers:

  • Testnet versus mainnet deployment strategies, including proxy upgrade procedures and post-upgrade verification.
  • Production Oracle deployment using Docker Compose, environment configuration, reverse-proxy exposure, and scaling considerations.
  • Monitoring and alerting through health checks, Prometheus metrics, divergence detection, and incident response.
  • Maintenance tasks such as contract upgrades, parameter tuning, and emergency procedures.
  • Security hardening, backup strategy, disaster recovery, governance processes, and upgrade safety mechanisms.

The repository currently documents a live Arc testnet deployment and an explicit mainnet readiness review; mainnet registries are not yet deployed. The testnet proxies were upgraded in place to the contracts on main on 26 October 2026, so the contract behaviour described below (the guardian pause, admin-ruled disputes, launch floors and ceilings, operator signers) is live there, apart from the bound on upholding a dispute, which they take at their next upgrade. The timelocked role grants are the exception: they come from role administrators written when a registry is initialised, and the testnet's were written by the 21 September code. The Oracle service is designed for production with token-gated write endpoints, unauthenticated read paths, rate limiting, persistent state, and checker-mode redundancy.

Section sources

Project Structure

At a high level, production concerns are split between:

  • Protocol contracts and deployment/upgrade scripts under script/.
  • The off-chain Oracle service under oracle/, with Docker Compose files at the repository root.
  • Documentation and runbooks under docs/ and oracle/.
graph TB
subgraph "Protocol"
DEPLOY["Deploy.s.sol"]
UPGRADE["Upgrade.s.sol"]
CONTRACTS["UUPS Proxies<br/>Identity / Reputation / Staking / Bond / Fees"]
end
subgraph "Oracle Service"
ORACLE["oracle/index.js"]
STORE["Persistent State<br/>oracle_state volume"]
METRICS["/metrics"]
HEALTH["/health"]
EVIDENCE["/evidence/:didHash"]
end
subgraph "Compliance & Redundancy"
CHECKER["Checker Operator"]
WATCHER["Divergence Watcher"]
end
subgraph "External"
RPC["Chain RPC"]
PROXY["Reverse Proxy / TLS"]
MONITOR["Prometheus / Alertmanager"]
end
DEPLOY --> CONTRACTS
UPGRADE --> CONTRACTS
ORACLE --> RPC
ORACLE --> STORE
ORACLE --> METRICS
ORACLE --> HEALTH
ORACLE --> EVIDENCE
CHECKER --> RPC
WATCHER --> CHECKER
WATCHER --> RPC
PROXY --> ORACLE
MONITOR --> METRICS
Loading

Diagram sources

Section sources

Core Components

  • Sigvara Identity: Agent registration, Ed25519 key management, bond-gated status transitions, and operator transfer.
  • Sigvara Reputation: Stores finalized scores, exposes threshold checks, and manages optimistic score proposals with challenge windows.
  • Sigvara Staking: Manages agent bonds, slashing lifecycle, suspension, unbonding, and slash distribution.
  • Sigvara Oracle Bond: Bonds oracle operators when enabled; only admitted bonded operators (or, on main, the signer one has named) may propose scores.
  • Sigvara Epoch Fees: Optional fee registry for scoring fees. It has never been deployed and is left out of the mainnet launch.
  • Oracle Service: Computes six-factor reputation scores, verifies payment-backed attestations, serves evidence, exposes metrics and health, and supports checker mode.

Key operational properties:

  • Contracts use UUPS proxies controlled by roles; on mainnet, admin rights target a Safe and upgrade rights a 48 hour timelock.
  • The Oracle service persists attestation and flag state to a mounted volume.
  • Read endpoints are intentionally unauthenticated and rate-limited; write endpoints require per-integration bearer tokens.

Section sources

Architecture Overview

The production system consists of on-chain registries and an off-chain Oracle that proposes scores backed by verifiable evidence. A second operator can run in checker mode, and a watcher alerts the slashing committee while proposals remain actionable.

sequenceDiagram
participant Client as "Client / CounterAudit / HoodScan"
participant Oracle as "Oracle Service"
participant Store as "Persistent State"
participant Chain as "Sigvara Contracts"
participant Checker as "Checker Operator"
participant Watcher as "Divergence Watcher"
participant Committee as "Slashing Committee"
Client->>Oracle : POST /attest (payment-backed or legacy)
Oracle->>Store : Record settlement / outcome
Oracle->>Chain : Query identity, feedback, staking
Oracle->>Oracle : Compute 6-factor score + Merkle root
Oracle->>Chain : proposeReputation(didHash, data, root)
Note over Chain : Challenge window open
alt Committee rejects during window
Committee->>Chain : rejectReputation(didHash)
else Window elapses unchallenged
Client->>Chain : finalizeReputation(didHash)
end
Checker->>Chain : Read pending score
Checker->>Checker : Recompute locally
alt Disagreement detected
Checker-->>Watcher : Divergence available
Watcher->>Chain : Re-check proposal status
Watcher-->>Committee : Actionable alert
end
Loading

Diagram sources

Detailed Component Analysis

Contract Deployment Strategy: Testnet vs Mainnet

  • Testnet: Deployer, oracle, and committee addresses are configurable; role separation is warned but tolerated because testnet assets have no economic value. The script writes chain-specific artifacts to deployments/{chainId}.json. A broadcast writes the file when forge runs the script locally, before the transactions confirm, so a failed or interrupted broadcast can leave it naming contracts that were never deployed. Do not use --resume; check every proxy against the chain before committing the file.
  • Mainnet: Role separation is enforced; deployer must not be oracle or committee, and the two must differ. On main, a pause guardian (GUARDIAN_ADDRESS) that is none of them is required as well. Admin and upgrade roles should move to a Safe and a timelock before mainnet launch. The SVR token address is supplied (a contract with 18 decimals) rather than deploying the testnet faucet token. The scripts also refuse the testnet default for the minimum stake and the oracle bond amount and anything under the published launch figures (10,000 SVR and 2,500,000 SVR), and a period or window outside the floors and ceilings the contracts enforce, naming the variable. DeployEpochFees.s.sol refuses to run on chain 5042 at all.

Deployment steps include simulating the script, broadcasting, recording the deploy block (the script writes it to the artifact as deployBlock), verifying parameters and role wiring, checking each proxy against the chain, committing the artifact, and pointing the Oracle service at the new contracts.

On mainnet the post-deploy assertions are in scripts/check-mainnet.sh, which is sourced and then called step by step (check_core, check_bond_and_fees, check_authority, check_timelock, check_safes, check_code, and check_new_implementation before the Safe schedules an upgrade). The addresses it expects come from the environment and not from the artifact, so a wrong artifact cannot vouch for itself, and a read that cannot reach the chain counts as a failure. scripts/check-role-holders.mjs replays every role grant and revocation from the deploy block and fails unless each role is held by exactly the expected addresses. Run it with BEFORE_RENOUNCE=1 after the Safe has removed the deployer's admin and before the last phase of SplitAuthority.s.sol (the deployer is then expected to hold UPGRADER_ROLE beside the timelock), and again without it after the handover. epochFees is checked only when the artifact has an entry for it.

flowchart TD
Start(["Start Deploy"]) --> Env["Export keys and parameters"]
Env --> Simulate["Simulate with forge script"]
Simulate --> CheckRoles{"Role separation OK?"}
CheckRoles --> |No| Warn["Review warnings / adjust roles"]
Warn --> Simulate
CheckRoles --> |Yes| Broadcast["Broadcast deploy"]
Broadcast --> RecordBlock["Record deploy block number"]
RecordBlock --> VerifyParams["Verify minimum stake, challenge periods, maturity rate"]
VerifyParams --> VerifyRoles["Verify STAKING_CORE_ROLE, ORACLE_ROLE, SLASHING_COMMITTEE_ROLE"]
VerifyRoles --> CheckProxies["Check each proxy on chain:<br/>record-implementations.mjs"]
CheckProxies --> CommitArtifact["Commit deployments/{chainId}.json"]
CommitArtifact --> PointOracle["Configure Oracle .env"]
PointOracle --> End(["Ready for Oracle epochs"])
Loading

Diagram sources

Section sources

Proxy Upgrade Procedures and Migration Scripts

All registries are UUPS proxies. Upgrades are performed via script/Upgrade.s.sol, which:

  • Reads the proxy address from the committed deployment artifact or an override.
  • Deploys a fresh implementation.
  • Calls upgradeToAndCall with optional initializer calldata.
  • Verifies the implementation slot changed.
  • Checks dependency ordering to avoid calling functions missing on older dependencies.
  • Refuses a PROXY override that is not the kind of contract TARGET names, since an implementation of one registry installs cleanly on another's proxy and bricks it.

The deployer key must hold UPGRADER_ROLE. After the handover that role belongs to the timelock, which this script cannot act as: it broadcasts with the key it is given and prints no timelock calldata. The upgrade then goes through the timelock. The implementation is deployed from any funded key, the Safe calls schedule(proxy, 0, upgradeToAndCall(impl, data), predecessor, salt, delay), and once the delay has run anyone calls execute. Reinitializers are DEFAULT_ADMIN_ROLE-gated and the timelock is not the admin, so data cannot be one: the upgrade lands with empty data and the Safe calls the reinitializer in a second transaction, which is why a new reinitializer needs an unset state that fails closed.

After an upgrade, record the live implementation addresses so the deployment artifact matches the chain. scripts/record-implementations.mjs reads the Arc testnet artifact by default and CHAIN_ID=5042 selects the mainnet one; it refuses an endpoint that reports a different chain from the artifact's, and --check fails if the file and the chain disagree.

sequenceDiagram
participant Dev as "Operator"
participant Script as "Upgrade.s.sol"
participant Chain as "UUPS Proxy"
participant Impl as "New Implementation"
participant Artifact as "deployments/{chainId}.json"
Dev->>Script : Set TARGET, optional INIT_CALLDATA, PROXY
Script->>Artifact : Read proxy address
Script->>Chain : Read current implementation slot
Script->>Impl : Deploy new implementation
Script->>Chain : upgradeToAndCall(newImpl, initData)
Script->>Chain : Read implementation slot again
Script-->>Dev : Log old/new implementations
Dev->>Dev : Run record-implementations.mjs --check
Loading

Diagram sources

Section sources

Oracle Service Production Deployment

The Oracle service computes and proposes reputation scores, verifies payment-backed attestations, and exposes public read endpoints plus token-gated write endpoints.

Production deployment essentials:

  • Use docker compose -f docker-compose.oracle.yml up -d.
  • Mount a persistent volume at /data for attestation and flag state.
  • Bind to localhost by default; expose only selected endpoints through a reverse proxy.
  • Configure .env with RPC URL, private key (or ORACLE_PRIVATE_KEY_FILE), contract addresses, EXPECTED_CHAIN_ID, and ORACLE_ADMIN_TOKEN; behind a reverse proxy also set TRUSTED_PROXIES.
  • Enable PAYMENT_VERIFICATION=required and set PAYMENT_ASSET for mainnet-grade security.
  • On mainnet use docker-compose.mainnet.yml: it builds from a pinned commit (SIGVARA_REF), reads the key from a file secret and runs read-only with every capability dropped.
flowchart TD
Start(["Compose Up"]) --> Build["Build oracle image"]
Build --> Env["Load .env variables"]
Env --> Persist["Mount oracle_state volume"]
Persist --> HTTP["Bind HTTP port (localhost)"]
HTTP --> Health["Serve /health"]
HTTP --> Metrics["Serve /metrics"]
HTTP --> Evidence["Serve /evidence/:didHash"]
HTTP --> Score["Serve /score/:didHash"]
HTTP --> Attest["Accept POST /attest (token policy)"]
Attest --> Verify["Verify payment on chain"]
Verify --> Epoch["Run epoch computation"]
Epoch --> Propose["proposeReputation on chain"]
Loading

Diagram sources

Section sources

Environment Configuration and Scaling Considerations

Required Oracle configuration includes RPC URL, private key, and contract addresses. Recommended production settings include admin tokens, EXPECTED_CHAIN_ID, persistent state path, attestation cooldown, and payment verification parameters. Numeric settings are checked at startup: a value that is set and unusable stops the process, and a blank value means unset.

Scaling guidance:

  • Keep read endpoints rate-limited; they rebuild Merkle trees and perform multiple RPC calls.
  • Run a separate checker operator on different hardware and RPC provider.
  • Run the divergence watcher on a third host with its own RPC provider.
  • Avoid sharing state volumes between primary and checker.
  • Tune payment scan pacing and confirmations to balance catch-up speed and RPC limits.
graph TB
Primary["Primary Oracle"]
Checker["Checker Operator"]
Watcher["Divergence Watcher"]
RPC1["RPC Provider A"]
RPC2["RPC Provider B"]
RPC3["RPC Provider C"]
Primary --> RPC1
Checker --> RPC2
Watcher --> RPC3
Watcher --> Checker
Loading

Diagram sources

Section sources

Monitoring and Alerting Setup

Monitoring relies on:

  • /health: Operational signals including epoch freshness (a primary that has never completed an epoch reports 503 once it has been up two epoch intervals), store writability, persistence status, where the state was loaded from (stateSource), the chain the RPC is on, external feed reachability, and payment scan progress.
  • /metrics: Prometheus-format counters for epochs, proposals, attestations, flags, links, evidence cache hits, and checker comparisons.
  • Divergence endpoint: Exposes disagreements for checker-mode operators.
  • Watcher: Polls checker divergence, re-verifies against chain, and alerts while proposals remain actionable. It also alerts when the checker is unreachable, unreadable, not a checker, or has not completed an epoch within MAX_SILENCE_MINUTES, and when its own polls fail three times in a row.

Alerting recommendations:

  • Scrape /metrics with Prometheus.
  • Alert on /health returning 503.
  • Watch failed epochs and rejected attestations due to cooldown.
  • Watch sigvara_oracle_tx_refused_total (a fee cap that trips, or a transaction never seen mined) and stateSource on /health (anything but file after a restart).
  • Alert on checker silence or inability to see proposals.
  • Alert on actionable divergences and final warnings near the challenge window close.
flowchart TD
Scrape["Prometheus scrapes /metrics"] --> Epochs["Epoch success/failure"]
Scrape --> Proposals["Propose/finalize attempts"]
Scrape --> Attests["Attest accept/reject/cooldown"]
Scrape --> Flags["Flags raised/resolved"]
Scrape --> Cache["Evidence cache hit/miss"]
Scrape --> Checker["Checker comparisons"]
HealthCheck["Health check probe"] --> HealthStatus["503 if stale/unwritable/unpersisted"]
Watcher["Divergence watcher"] --> Divergence["GET /divergence"]
Divergence --> Classify["Classify actionable/expired/superseded/closed"]
Classify --> Alert["Send webhook/alert"]
Loading

Diagram sources

Section sources

Maintenance Tasks: Contract Upgrades, Parameter Tuning, Emergency Procedures

  • Contract upgrades: Use script/Upgrade.s.sol with TARGET and optional INIT_CALLDATA; verify dependency ordering and implementation slot change; commit live implementations afterward. After the handover the upgrade goes through the timelock instead (see above).
  • Parameter tuning: Adjust Oracle environment variables such as epoch interval, payment verification thresholds, half-life decay, max-per-payer caps, and scan pacing. A container reads its env_file when it is created, so apply a change with docker compose up -d; a plain restart re-runs the start command but keeps the old environment.
  • Emergency procedures:
    • If a score proposal looks wrong, the slashing committee can reject it with rejectReputation within the challenge window.
    • If an agent key is compromised, suspend the agent, rotate the key, then reinstate.
    • If the Oracle service cannot persist state, stop exposing write endpoints until storage is restored.
    • On main, a slash that is wrong can be vetoed by the admin Safe while it is pending or disputed, and a live bug can be contained by the guardian key, which pauses new registrations, stake deposits, score proposals and bond deposits for three days at a time. A pause never covers withdrawals, disputes, rulings, slash execution or finalization, and the admin can lift it or revoke the guardian at once. The testnet contracts have neither.
flowchart TD
Start(["Maintenance Trigger"]) --> Decide{"Type of maintenance"}
Decide --> |Contract Change| Upgrade["Run Upgrade.s.sol"]
Decide --> |Policy Change| TuneEnv["Update Oracle .env"]
Decide --> |Security Incident| Suspend["Suspend agent / rotate key"]
Decide --> |Service Failure| Recover["Restore state / restart service"]
Upgrade --> VerifyImpl["record-implementations.mjs --check"]
TuneEnv --> Restart["Recreate Oracle container<br/>(docker compose up -d)"]
Suspend --> Reinstate["Reinstate after recovery"]
Recover --> HealthCheck["Validate /health and /metrics"]
Loading

Diagram sources

Section sources

Security Hardening, Backup Strategy, Disaster Recovery

Security hardening:

  • Do not bind the Oracle service to all interfaces without a reverse proxy. The service refuses a non-loopback bind with no write credential.
  • Set ORACLE_ADMIN_TOKEN before exposing any write endpoints.
  • Set EXPECTED_CHAIN_ID, and keep the signing key in a file secret (ORACLE_PRIVATE_KEY_FILE) rather than in the environment.
  • Require payment verification on mainnet and configure the correct payment asset.
  • Ensure oracle wallet is bonded and admitted (or, on main, is the named signer of a bonded operator) when operatorBond is enabled.
  • Separate roles: deployer, oracle, committee and guardian should be distinct; mainnet enforces this.

Backup strategy:

  • Persist Oracle state to a dedicated volume (oracle_state).
  • Back up the state file regularly; attestations not persisted are lost on restart. Copy it off the host: the <state>.bak the oracle keeps is one save behind and on the same disk.
  • Keep deployment artifacts and recorded implementations synchronized with the chain.

Disaster recovery:

  • Restore state from backups before restarting the Oracle service. A state file that exists but cannot be read falls back to the .bak, and with no usable backup the process stops rather than start empty.
  • If the checker becomes unreachable, the watcher alerts; ensure the watcher runs on a separate host.
  • If a proposal is missed by the checker, rely on the slashing committee’s reject capability within the challenge window.

Section sources

Operational Runbooks

Common operational tasks:

  • Deploy to testnet: simulate, broadcast, record block, verify parameters and roles, check every proxy against the chain, commit artifact, point Oracle at contracts.
  • Run Oracle locally: copy .env.example, configure RPC and keys, run node index.js, validate epochs.
  • Deploy Oracle via Docker Compose: bring up service, mount state volume, expose through reverse proxy. On mainnet a deploy is a change to SIGVARA_REF followed by docker compose up -d.
  • Add a second operator: fund bond, admit operator, grant ORACLE_ROLE, set checker mode, separate state and RPC.
  • Monitor divergence: run watcher, configure webhook (WEBHOOK_URL; without it alerts reach the container log only), watch actionable alerts.

Section sources

Troubleshooting Guide for Production Issues

  • /health returns 503:
    • State path not writable or last state write failed.
    • No successful epoch in the last two times the epoch interval (counted from process start until the first success).
  • /attest returns 402 or 409:
    • Payment did not check out or settlement already credited.
  • /attest returns 202:
    • Accepted, but the oracle could not save its state file (durable: false). Do not resend; /health is 503 until a save works.
  • /attest returns 429:
    • Cooldown active; wait for remaining seconds.
  • /attest returns 502:
    • RPC failure; retry later.
  • Checker divergence:
    • Review /divergence, classify whether actionable, expired, superseded, or closed.
    • Ensure watcher is running on a third host and has a different RPC provider.
  • Evidence audit mismatch:
    • Rebuild Merkle root from served evidence and compare with on-chain evidenceRoots.
    • Use verifyEvidence to validate individual leaves.

Section sources

Dependency Analysis

The deployment and upgrade scripts depend on OpenZeppelin proxies and the protocol contracts. The Oracle service depends on chain RPCs, contract addresses, and optionally external feeds. The checker and watcher depend on independent RPC providers and separate state.

graph TB
Deploy["Deploy.s.sol"] --> Identity["SigvaraIdentity"]
Deploy --> Reputation["SigvaraReputation"]
Deploy --> Staking["SigvaraStaking"]
Deploy --> Token["SVRToken"]
Upgrade["Upgrade.s.sol"] --> Identity
Upgrade --> Reputation
Upgrade --> Staking
Upgrade --> Bond["SigvaraOracleBond"]
Upgrade --> Fees["SigvaraEpochFees"]
Oracle["Oracle Service"] --> Reputation
Oracle --> Identity
Oracle --> RPC["Chain RPC"]
Checker["Checker"] --> RPC
Watcher["Watcher"] --> RPC
Loading

Diagram sources

Section sources

Performance Considerations

  • Oracle epoch cadence should be shorter than half the reputation challenge window so the checker can observe proposals before they expire.
  • Payment scanning pace must respect RPC rate limits; default pacing avoids bucket exhaustion during long catch-ups.
  • Evidence cache reduces expensive Merkle tree rebuilds; monitor hit rates.
  • Badge endpoint caches results to reduce repeated RPC calls.
  • Rate-limit read endpoints to prevent enumeration and expensive recomputation.

Troubleshooting Guide

See the detailed troubleshooting section above for common error codes, divergence classification, and evidence auditing steps.

Section sources

Conclusion

Sigvara’s production model combines UUPS-upgradeable contracts with a robust Oracle service, checker-mode redundancy, and divergence alerting. Testnet deployment is straightforward, while mainnet requires strict role separation, governance controls, and payment-verified attestations. Operators should treat upgrades as high-risk operations, back up Oracle state, monitor health and metrics closely, and maintain independent RPC providers across primary, checker, and watcher components. Governance and upgrade safety are central: only authorized roles can upgrade, and the slashing committee retains the ability to reject bad proposals within the challenge window.

Appendices

Governance Processes and Upgrade Safety Mechanisms

  • Roles:
    • UPGRADER_ROLE authorizes upgrades and, on main, the wiring of the stake view, reputation's operator bond registry and the slash beneficiary (on the Arc testnet proxies the admin does that); on mainnet it belongs to a 48 hour timelock. On main it also administers itself and the roles that move funds or change an agent's standing (the slasher, committee and staking core roles), so granting one takes the delay.
    • DEFAULT_ADMIN_ROLE is the admin Safe on mainnet. On main it sets parameters within their floors and ceilings, grants ORACLE_ROLE and GUARDIAN_ROLE, revokes any role except UPGRADER_ROLE, rules on disputed slashes and can veto a pending or disputed one.
    • STAKING_CORE_ROLE allows staking actions on identity and reputation.
    • ORACLE_ROLE permits proposing scores; when operatorBond is set, the oracle must also be admitted and bonded, or be the signer an admitted operator has named (on main).
    • SLASHING_COMMITTEE_ROLE initiates and cancels slashes and rejects bad scores within the challenge window. On main it does not rule on disputes.
    • GUARDIAN_ROLE (on main) pauses new inflows for three days at a time, and nothing else.
    • The Arc testnet proxies have run this code since 26 October 2026, but their role administrators were written by the September code, so the admin also grants the slasher, committee and staking core roles there.
  • Upgrade safety:
    • Upgrade.s.sol validates dependency ordering and implementation slot changes, and refuses a proxy that is not the kind its target names.
    • Post-upgrade, record live implementations and verify with scripts/record-implementations.mjs --check.
  • Mainnet readiness:
    • Move admin rights to a Safe and upgrade rights to a timelock with script/SplitAuthority.s.sol (rehearsed on a fork of the testnet, not yet run on a live deployment).
    • The documented end-to-end testnet slash is done (executed 3 October 2026). The tier-1 audit is not.

Section sources

Home

Overview

Protocol Architecture

Smart Contracts Reference

Oracle Service

Reputation System Design

TypeScript SDK

Integration Guides

Deployment and Operations

Development and Testing

Advanced Topics

Clone this wiki locally