> 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/hrn-clean-launch.md).

# HRN Clean Launch Operations

This runbook governs the terminal retirement of tHARENA and a possible phase-1 launch of direct-HRN skill licenses. It is a pre-launch checklist, not a statement that Harena currently accepts HRN.

## Fixed Product Boundary

* tHARENA has zero redemption or conversion into HRN. Historical balances are archived evidence only.
* Skill, agent, manifest and performance metadata may carry forward for provenance or catalog continuity. Balances, licenses, run allowances, prize rights, payment credits and all other economic entitlements do not carry forward.
* Phase 1 is limited to direct-HRN skill-license purchases.
* Arena entry, competition prizes and LLM usage billing remain Demo/Test functions and are not HRN in phase 1.
* No operator may use a migration ratio, allocation file or discretionary transfer to recreate historical tHARENA value in HRN.

## 1. Terminal tHARENA Retirement

* [ ] Declare one UTC cutoff and identify the accountable operator and approvers.
* [ ] Freeze all tHARENA economic writes, disable the faucet, and remove or block every issuance, purchase, compute-charge, entry-fee, prize and unfreeze path.
* [ ] Drain or classify pending orders, execution outbox records and unapplied fills before the snapshot.
* [ ] Close, void or otherwise record the disposition of every open competition, pool and historical license without creating an HRN entitlement.
* [ ] Reconcile issuance, user balances, treasury balances and every posting to zero unexplained difference.
* [ ] Verify the application audit chain and record its terminal event count and hash.
* [ ] Establish a **no-unfreeze terminal state**. Confirm through configuration, permissions and a restart test that no operator command, scheduler, worker or public endpoint can resume tHARENA mutation.
* [ ] Complete at least one new post-snapshot arena season. Legacy entries with blank strategy provenance remain PAPER and must not be backfilled as VERIFIED.

## 2. Retirement Manifest and Archive

Create a signed or otherwise approval-bound manifest containing:

* UTC cutoff, environment, database identity and schema/migration versions;
* source revision and hashes of the deployed application artifacts;
* final economic mode and revision;
* account, issuance, user-transaction and treasury-transaction totals;
* competition, pool, license, order, outbox, fill and audit-chain disposition;
* hash of the canonical database dump and any structured ledger exports;
* hashes or immutable references for the Terms, Risk Disclosure, Privacy Notice and this runbook effective at cutoff;
* explicit text stating zero tHARENA redemption/conversion and zero carried economic entitlement;
* operator, reviewer and approval timestamps.

Archive the manifest and evidence in encrypted, access-controlled storage with at least one off-site immutable copy. Define retention and deletion rules with privacy and legal review. Complete a restore drill into an isolated database, rerun reconciliation and audit verification, and attach the results to the manifest. A dump that has only been created or listed is not a validated archive.

## 3. Contract and Deployment Gates

* [ ] Freeze the exact marketplace source, compiler version, optimizer settings, constructor arguments and expected creation/runtime bytecode.
* [ ] Complete the internal contract release review, record required test coverage, and resolve or formally accept every finding.
* [ ] Run unit, fuzz, stateful invariant, adversarial-token, replay, reentrancy and BSC fork compatibility tests.
* [ ] Deploy without enabling product access, verify source publicly, and reproduce the runtime code hash from the approved build.
* [ ] Verify the HRN token, BSC chain ID, marketplace address, skill IDs, treasury addresses and every contract role independently.
* [ ] Place administration and treasury control under approved multisig/timelock governance. Keep the runner in KMS or an equivalent managed signer with least privilege, rotation, rate limits and an emergency revocation path.
* [ ] Document pause authority, separation of duties, signer compromise response and the approvals required to resume after an incident.

## 4. Contract-to-Entitlement End-to-End Validation

For each test purchase, validate the complete business event rather than a generic token transfer:

1. Generate a nonzero, globally unique `purchaseRef` from the immutable off-chain business record.
2. Confirm chain 56, the exact HRN and marketplace addresses, skill terms, allowance target and price before wallet approval.
3. Revalidate the canonical-block blacklist, balance and allowance state, issue one short signing lease, then submit the exact `buyLicenseChecked(...)` calldata and store the transaction hash without granting access immediately.
4. Wait for the approved finality policy and verify canonical transaction success.
5. Verify the indexed `skillId`, buyer and `purchaseRef` in `LicensePurchased`, together with price, term, run limit and all creator/protocol/arena HRN transfers.
6. Bind that evidence exactly once to the intended account, skill version and entitlement. Reject reused references, mismatched wallets, partial evidence and unknown skill IDs.
7. Recheck confirmed evidence for reorgs. Suspend affected entitlements and alert operators rather than silently preserving non-canonical payment state.
8. Reconcile on-chain events, treasury receipts and application entitlements to zero unexplained difference.

Tests must cover duplicate submissions, delayed receipts, RPC disagreement, reverted or partially observed transactions, finality fallback, reorgs, paused contracts, role rotation and application restarts.

## 5. Capped Canary

* [ ] Use one explicitly approved skill and conservative price and volume caps.
* [ ] Allowlist a small set of controlled buyer wallets; do not open general access.
* [ ] Use isolated canary treasury destinations and pre-approved signer limits.
* [ ] Exercise purchase, entitlement use, expiry, run exhaustion, replay rejection, pause and reorg response.
* [ ] Reconcile every transfer and entitlement manually and automatically.
* [ ] Hold a written go/no-go review after the observation window. Expansion requires positive approval; elapsed time is not approval.

## 6. Monitoring and Incident Response

Alert an accountable on-call operator for:

* RPC failure, wrong chain ID, HRN or marketplace bytecode mismatch and stalled block progress;
* pending purchases beyond the service objective, finality lag and provider disagreement;
* removed logs, block-hash changes and any confirmed receipt that becomes non-canonical;
* duplicate `purchaseRef`, unknown event, transfer/event mismatch or entitlement without complete canonical evidence;
* creator, protocol and arena transfer totals that do not equal the event price;
* pause, unpause, admin, runner or treasury role changes;
* KMS signing errors, unexpected signing volume and authorization failures;
* reconciliation drift between on-chain purchases and active application entitlements.

Dashboards alone are insufficient. Test alert delivery, escalation, contract pause, signer revocation, entitlement suspension and evidence preservation before the canary.

## 7. Refund and Recovery Policy

Before accepting HRN, publish and operationally approve how each of these cases is handled: wallet rejection, reverted transaction, duplicate submission, wrong chain or address, successful irreversible purchase, delayed finality, reorg after provisional recognition, incorrect skill terms, compromised treasury or runner, and product inability to deliver the licensed access.

The policy must identify who can authorize a refund or replacement entitlement, the funding source, required evidence, approval threshold, destination-wallet verification and reconciliation entry. Never promise automatic reversal of an on-chain transfer. Never ask for a private key or seed phrase, and do not improvise refunds through an unreviewed operator wallet.

## 8. Final Go/No-Go Record

The launch approvers must sign a record that links the retirement manifest, legal documents, internal release review and test results, verified deployment, role register, canary results, monitoring evidence, restore drill and incident/refund procedures. Any missing or stale artifact is a no-go. If phase 1 is paused, HRN purchases remain disabled while already-finalized records are preserved for reconciliation; tHARENA remains permanently retired and must not be unfrozen as a fallback.


---

# 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/hrn-clean-launch.md?ask=<question>&goal=<user_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.