docs: record the mainnet events 1.8.0 and profile 1.2.1 upgrade

BACKLOG.md

@@ -9,16 +9,15 @@ Legend: `[ ]` open, `[~]` in flight, `[x]` done.
 ## P0
 
 - [ ] Third-party security audit (events + profile). Cost ~$30-80k for a Soroban-experienced firm. Scope it to the 2.0.0 / 1.2.1 tree.
-- [ ] **Upgrade mainnet to events 1.8.0 + profile 1.2.1** (`docs/upgrade-runbook.md`, Section 8). Events 1.8.0 is the 2.0.0 code under a 1.x label (tag `events-v1.8.0`), so the backend keeps grants and held-refund claims off on mainnet until a 2.x upgrade. Carries every threat-model fix (`docs/threat-model.md` v1.1, Section 4.1.2), restores the 17,280-ledger upgrade timelock (EoP.10: the deployed 1.7.0 / 1.2.0 builds have none), and finishes the 1.7.0 migration that never ran: events still reports a 1.6.0 marker, and events 1 and 2 (`…609`, `…610`, both Completed with zero escrow) are still in the old layout and fail to decode. Rehearsed on testnet 2026-10-02 (events `CBEODVJG…` at 2.0.0, 185 events through `migrate_events`, `migrate` stamped). Backend first: read pages of 90, refund cranks of 15, hackathon selections split at 20 per call, `forfeit_milestone` on milestone rejection, `claim_refund` for held refunds, and no calls to the removed participation entry points. Then profile propose / apply / migrate, and events pause / propose / apply / one `migrate_events` page / `migrate` / unpause, all under the deployed zero timelock. `deploy_mainnet.sh` now refuses to unpause events until `migrate` has stamped, the gate the August upgrade lacked.
 
 ## P1
 
-- [ ] **Events 2.1.0 (grant milestone splits) to mainnet**, as its own upgrade after 1.8.0, waiting the 17,280-ledger timelock. Before it goes: rerun Scout on the 2.1.0 code and add it to `docs/threat-model.md` Section 6 (the scan covers 2.0.0; the testnet grant run already passed on 2.1.0, `docs/audit/testnet-grant-run-2.1.0.md`). Refresh the storage replay from 1.8.0 once mainnet runs it (`docs/storage-compatibility.md`).
+- [ ] **Events 2.1.0 (grant milestone splits) to mainnet**, as its own upgrade after 1.8.0, waiting the 17,280-ledger timelock. Before it goes: rerun Scout on the 2.1.0 code and add it to `docs/threat-model.md` Section 6 (the scan covers 2.0.0; the testnet grant run already passed on 2.1.0, `docs/audit/testnet-grant-run-2.1.0.md`). Refresh the storage replay from 1.8.0 first, which mainnet runs since 17 October 2026 (`docs/storage-compatibility.md`).
 - [ ] Per-event prize claim window: `PRIZE_CLAIM_WINDOW_SECS` (90 days) is a module constant because adding a field to `EventRecord` requires a storage migration. Move it onto `EventRecord` at the next real migration window, per the per-event-config rule in `CLAUDE.md`.
 - [ ] `Error` enum headroom: events uses 42 of the 50-case `contracterror` cap after 2.0.0, and retired codes are never reused. Plan a consolidation before the cap, not when the next variant fails to compile.
 - [ ] Grant committee multi-sig primitive (dedicated signer set + quorum at the contract level vs the current address-level multi-sig).
 - [ ] Multi-token support audit: verify the whitelist mechanism handles tokens with non-Stellar 7-decimal scales (currently assumed uniform).
-- [ ] Decide whether to appoint a crowdfunding release validator on mainnet once 1.8.0 is live, and who holds the key (`docs/admin-custody-policy.md` §4.1). Until one accepts, the admin multisig co-signs every crowdfunding release.
+- [ ] Decide whether to appoint a crowdfunding release validator on mainnet now that 1.8.0 is live, and who holds the key (`docs/admin-custody-policy.md` §4.1). Until one accepts, the admin multisig co-signs every crowdfunding release.
 
 ## P2 (roadmap)
 
@@ -30,6 +29,8 @@ Legend: `[ ]` open, `[~]` in flight, `[x]` done.
 
 ## Done
 
+- [x] 2026-10-17: mainnet upgraded to events 1.8.0 (the 2.0.0 code, tag `events-v1.8.0`) and profile 1.2.1 (`docs/upgrade-runbook.md`, Section 8, with every transaction hash). Both migrated and unpaused, the 17,280-ledger timelock is live, and events 1 and 2 were converted and read again. Grants and held-refund claims stay off on mainnet until a 2.x upgrade.
+
 - [x] 2026-10-02: measured batch headroom on the test host, which enforces mainnet limits (100 footprint entries, 50 writes): single-release selection 19 + 4 per award, grant selection 15 + 2 per award, refund crank 11 + 5 per refund, read page 3 + 1 per row. Caps are now 20 single-release awards per call, 40 per grant, 15 refunds per crank and 90-row pages, each tested at its maximum (`grant_scenarios::limits`).
 - [x] 2026-10-02: upgrade timelock restored in source (events 2.0.0, profile 1.2.1): 17,280 ledgers on mainnet builds, 0 with `--features testnet`; tests assert `UpgradeTimelockNotElapsed`.
 - [x] 2026-09-28: on-chain participation removed in events 2.0.0 (`apply`, `apply_to_bounty`, `remove_applicant`, `submit` and their registries); entries live in boundless-nestjs.

README.md

@@ -13,8 +13,8 @@ earnings.
 
 | Network | Contract | Address | Version |
 |---------|----------|---------|---------|
-| Mainnet | `boundless-events` | `CCFVEGOQJEM47LRAJU2LHEK4KTL5VYN7AOGZ2HH2GNHAMXTILNMMJGQZ` | `1.7.0` |
-| Mainnet | `boundless-profile` | `CD3KH4OE7HDHHHUYFX3U4L7NLIILMXAY6HM5FEH2UH6UBOKX4HDNE3PC` | `1.2.0` |
+| Mainnet | `boundless-events` | `CCFVEGOQJEM47LRAJU2LHEK4KTL5VYN7AOGZ2HH2GNHAMXTILNMMJGQZ` | `1.8.0` |
+| Mainnet | `boundless-profile` | `CD3KH4OE7HDHHHUYFX3U4L7NLIILMXAY6HM5FEH2UH6UBOKX4HDNE3PC` | `1.2.1` |
 | Testnet | `boundless-events` | `CBEODVJGUYCIYTVXD7KI5UG3BJ2UE4T7AGI2TGY3T4Q5GQRFGTRYVTZP` | `2.1.0` |
 | Testnet | `boundless-profile` | `CCA3OAIBOZBUPHPRI5GI6N5PDTE7RTNLKAEID4JTC2YZIHIZNDX5Q6T3` | `1.2.1` |
 

docs/multisig-guide.md

@@ -577,7 +577,7 @@ On the events contract the admin **can:**
 - Change the default fee rate (`set_fee_bps`).
 - Change the fee account address (`set_fee_account`). This one needs all three signatures.
 - Pause the contract in an emergency (`pause`) and resume after a fix (`unpause`).
-- Propose a contract upgrade (`propose_upgrade`). On current mainnet builds the upgrade cannot apply until about a day (17,280 ledgers) after the proposal, so users can see it coming. The deployed events 1.7.0 and profile 1.2.0 builds have no such wait; the 1.8.0 upgrade restores it.
+- Propose a contract upgrade (`propose_upgrade`). On current mainnet builds the upgrade cannot apply until about a day (17,280 ledgers) after the proposal, so users can see it coming. Every mainnet build since the events 1.8.0 and profile 1.2.1 upgrade on 17 October 2026 has this wait; the 1.7.0 and 1.2.0 builds before it did not.
 - Apply a proposed upgrade after that wait (`apply_upgrade`), or cancel it (`cancel_pending_upgrade`).
 - Run the post-upgrade migration (`migrate_events`, then `migrate`).
 - Add or remove tokens from the whitelist (`register_supported_token`, `deregister_supported_token`).

docs/storage-compatibility.md

@@ -2,7 +2,7 @@
 
 `contracts/compatibility` replays the next mainnet upgrade against real mainnet
 storage. It loads contract data captured from a mainnet ledger, runs the builds
-deployed on mainnet today, then proposes, applies and migrates the release build
+deployed on mainnet at that ledger, then proposes, applies and migrates the release build
 of this tree the way `docs/upgrade-runbook.md` does it on chain:
 
 1. Read every event, every winner record and the reputation of every winner
@@ -59,7 +59,7 @@ To check that the fixture still reproduces from the history archive (Stellar CLI
 
 ## Refreshing for the next upgrade
 
-Once mainnet runs 1.8.0 (tag `events-v1.8.0`), the replay should start from 1.8.0 instead:
+The fixtures still hold events 1.7.0 and profile 1.2.0. Mainnet has run events 1.8.0 (tag `events-v1.8.0`) and profile 1.2.1 since 17 October 2026, so before the next mainnet upgrade the replay should start from those builds:
 
 1. Fetch the deployed wasm for both contracts by hash into the fixtures
    directory and replace the two `mainnet-*.wasm` files.