> For the complete documentation index, see [llms.txt](https://harena.gitbook.io/harena-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://harena.gitbook.io/harena-docs/multisig-governance.md). # Multisig Governance Operations The Safe operations portal is a local operator surface for one BNB Smart Chain Harena Online Safe. It listens only on `127.0.0.1:3101` by default, has no public proxy route, and must not receive private keys, seed phrases, hardware-wallet recovery material, or managed-runner credentials. ## Control separation | Control | Address | Permitted purpose | Must remain separate from | | ----------------------------- | --------------------------- | ------------------------------------------------------------------------ | --------------------------------------------- | | Harena governance and custody | `HARENA_SAFE_ADDRESS` | Market administration plus capped HRN transfers to approved destinations | Market, token and runner contracts/identities | | Market runner | `HRN_MARKET_RUNNER_ADDRESS` | Narrow, automated market operations | The Safe and every Safe owner credential | The runner is an operational signer, not a governance owner. Keep it in a dedicated managed signer with a separate identity, policy, rotation schedule, rate limits, monitoring, and revocation procedure. A runner compromise must not provide Safe ownership; a Safe owner compromise must not provide runner access. ## Owner setup 1. Use individually controlled hardware wallets. Do not use a shared seed, browser hot wallet, server-held key, or the runner identity as an owner. 2. Record each proposed owner address through two independently observed channels before adding it to `MULTISIG_OWNER_ALLOWLIST`. 3. Configure the Safe with a threshold of at least two. Set `MULTISIG_MIN_THRESHOLD` to the approved minimum; it cannot exceed the allowlisted owner count. 4. Put the approved Safe singleton/master-copy addresses in `MULTISIG_ALLOWED_SINGLETONS`. This setting is required and has no default. Confirm the deployed address and chain independently before accepting it. 5. Keep Safe modules disabled. The launch verifier rejects any enabled module because a module can bypass normal owner-threshold execution. 6. Leave `MULTISIG_ALLOWED_GUARDS` empty when no guard is approved; in that state every Safe must report the zero guard. If a guard is intentionally used, list only its approved deployed address. An unreadable guard state is a failed check. 7. Confirm `HARENA_SAFE_ADDRESS` is the expected deployed BSC Safe and that the market admin, protocol treasury, and arena reserve roles all bind to it. Confirm it differs from `HRN_MARKET_RUNNER_ADDRESS`, the market contract and the HRN token. 8. Perform a recovery exercise for a lost owner and document who may approve owner replacement. Never reduce the threshold merely to make routine operations faster. The owner allowlist constrains the expected on-chain owner set; it is not a substitute for the Safe contract threshold. The read-only verifier checks both. ## Configuration Copy `.env.example` to the protected runtime environment and set `HARENA_SAFE_ADDRESS`, the `MULTISIG_*` policy, and direct-HRN contract variables. `SAFE_API_KEY` and an RPC URL containing credentials are runtime secrets and are deliberately not Docker build arguments. Restrict the environment file to the service operator account. `MULTISIG_TRANSFER_ALLOWLIST` is a comma-separated destination list. `MULTISIG_MAX_TRANSFER_WEI` is a positive integer in atomic HRN units. Start with the smallest practical allowlist and limit. Changes to either require the same recorded approval process as a treasury policy change. The reversible predeployment default permits only `0x24C2a63e8C5e8c52f13F64495E9f6E8cc987f548` and caps each proposal at `1 HRN` (`1000000000000000000` atomic units). This policy moves no funds by itself and remains inactive until the Market address and authenticated mutation service are configured. `HARENA_SAFE_ADDRESS` is the sole governance/custody address. The marketplace verifier positively requires its `admin`, `protocolTreasury`, and `arenaReserve` getters to equal this address; it does not infer safety merely because duplicate environment values were supplied. ## Start and verify The core API must be running before the combined check because it hosts the read-only governance management command. ```bash make multisig-up make multisig-check ``` `make multisig-check` first validates the Compose model and the portal health endpoint. It then queries chain 56 through the backend's read-only RPC client and fails unless all of the following hold: * the configured market code, HRN code, chain ID, token decimals, pause state, and market roles match; * admin, protocol treasury, and arena reserve roles all resolve to the configured Harena Online Safe; * the Safe reports an allowlisted singleton, the exact allowlisted owner set, and a threshold at or above the configured minimum; * the Safe has zero enabled modules and a zero or explicitly allowlisted guard; * the runner role matches the market and is separate from the Safe. The verifier exposes no signing or transaction-send method. A successful result is a current read-only observation, not continuing authorization; rerun it immediately before a mode transition and after every owner, threshold, module, guard, runner, or market-role change. Use `make multisig-logs` for local diagnostics and `make multisig-down` when the operator session ends. Confirm the host firewall does not publish port 3100. For remote access, use an authenticated tunnel to the loopback listener rather than adding a proxy route: ```bash ssh -N -L 3101:127.0.0.1:3101 operator-host ``` ## Operator session rules * Use the portal from a dedicated administrative workstation and an isolated browser profile. * Compare the Safe address, chain ID, nonce, target, value, decoded call, and policy result on the hardware-wallet display or the official Safe interface before any owner signs. * Keep proposal preparation, independent review, and threshold approval with different people where staffing permits. * Stop on an unexpected owner, singleton, module, guard, role, nonce, destination, amount, or decoded call. Preserve the read-only check output and investigate the drift. * If the runner is suspected compromised, revoke or rotate it through the Harena Online Safe and suspend runner automation. Do not reuse a Safe owner key as the replacement runner. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://harena.gitbook.io/harena-docs/multisig-governance.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.