[palango]

Five pages still told readers to use Alfajores, which is retired, and the ODIS page's endpoint table was dead for mainnet too: every cloudfunctions.net URL on it returns 404. This moves the live instructions to Celo Sepolia and removes the release runbook for the attestation service, which no longer exists; the deletion and its redirects follow the pattern #2293 used for orphaned pages. Pages that mention Alfajores as history stay as they are. Closes #2290.

What changed

Page	Change
build/tools/libraries-sdks/contractkit/odis.mdx	URL and key tables are now mainnet and Celo Sepolia, staging dropped. Values come from social-connect packages/identity/src/odis/query.ts and match the published @celo/identity@6.0.0-beta.0. Adds the getServiceContext(OdisContextName.CELO_SEPOLIA) snippet for 6.0.0-beta.0+, and says 5.1.2 needs the values passed in by hand.
build/tools/libraries-sdks/contractkit/setup.mdx	Prose says Celo Sepolia; the code already used the Sepolia RPC.
build/tools/contracts/uniswap-contracts.mdx	Drops the v3 Alfajores column and corrects the <Info> box, which claimed v3 was on Celo Sepolia.
build/tools/libraries-sdks/portal/index.mdx	eip155:44787 → eip155:11142220 in the gateway config and the four receiveTestnetAsset examples.
learn/protocol/transactions/transaction-types.mdx	The viem example imports celoSepolia instead of celoAlfajores.
contribute-to-celo/release-process/attestation-service.mdx	Deleted. It redirects to /contribute-to-celo/release-process, and the two older redirects that landed on it now go there directly. The nav entry and the link on the overview page are gone.

migrating-to-viem.mdx, listed in the issue, was already clean on main.

Caveats

• I could not verify the Portal change. Portal's chain list still names only Alfajores as a Celo testnet, and its RPC gateway returns 401 without an API key, so nothing confirms that eip155:11142220 works for the gateway or for receiveTestnetAsset. If it does not, the faucet link already on the page still works. A <Warning> under the initialization examples says this and tells readers to confirm support with Portal.
• I found no Uniswap v3 deployment on Celo Sepolia. The Alfajores and mainnet v3 addresses have no code on Celo Sepolia (eth_getCode returns 0x), and Uniswap's v3 Celo deployment page has only CELO and Alfajores columns. The page now says v3 has no published Celo Sepolia deployment and points testers at v4. If a deployment exists somewhere, the column can come back with checked addresses.
• Both ODIS combiners answer GET /status with {"version":"3.3.3"}. I did not run an identifier lookup, which needs an account with ODIS quota.
• Left for later, tracked in ODIS page: update the WalletKeySigner example for @celo/identity 6.0 #2365: the ODIS page's auth examples pass contractKit to WalletKeySigner, which is the 5.x API. @celo/identity 6.0.0 switches that to sign191, and only 6.0.0-beta.0 is published, so the example changes when 6.0.0 ships as latest.

Verification

• rg -il 'alfajores|44787' --glob '*.mdx' . returns 13 pages. All are history, migration notes or the Celo Sepolia pages that replace Alfajores, which the issue lists as out of scope.

• mint validate, mint broken-links --check-redirects and scripts/check-orphans.sh pass after the rebase onto main.

• mint dev: all three attestation-service paths return 307 to /contribute-to-celo/release-process, and the five edited pages return 200.

• I ran the ODIS getServiceContext snippet, as written on the page plus two console.log lines, in an empty directory with Node 24.21.0, using the install line the page now shows:

  $ npm install @celo/identity@6.0.0-beta.0 viem
  $ node snippet.mts
  https://odis-combiner.celo-sepolia.celo-testnet.org
  https://odis-combiner-mainnet.rc1-europe-west1.celo-testnet.org
  

  The first line is getServiceContext(OdisContextName.CELO_SEPOLIA).odisUrl, the second the same for MAINNET. The beta fails to import without viem, so the page installs both.

[GigaHierz]

head d306f47 · Check for broken links pass (CI) · ODIS URLs and keys rechecked against social-connect source · @celo/identity 5.1.2 and 6.0.0-beta.0 inspected from npm · Uniswap v3 addresses checked with eth_getCode on both networks · no e2e (docs only)

REQUEST-CHANGES. Three findings, all small; one is a live example the sweep missed.

Findings

1. Medium · home/protocol/transactions/transaction-types.mdx:309,331,335. The viem example still imports celoAlfajores from viem/chains and uses it for both clients (chain: celoAlfajores, // Celo testnet). This is a live instruction, not history, and it is the same class as the six pages this PR fixes (#2290). A reader who copies it points at the retired network.
   Fix: import and use celoSepolia (it exists in viem/chains; I checked the current package) and change the comment to "Celo Sepolia testnet".

2. Low · tooling/libraries-sdks/portal/index.mdx (five eip155: examples). The swap to eip155:11142220 is unverified, as the PR body says. Portal's own chain list names Celo mainnet (eip155:42220) and Alfajores (eip155:44787) and does not mention Celo Sepolia. The old value was already dead, so this is not worse than before, but the page now states a chain ID Portal does not document.
   Fix: either confirm with Portal that Celo Sepolia is supported and note it here, or add one line under the first example: "Portal's chain list does not yet name Celo Sepolia; confirm support with Portal before relying on it."

3. Low · tooling/contracts/uniswap-contracts.mdx:3. The frontmatter description still reads "Uniswap v4 and v3 contract addresses on Celo Mainnet and the Celo Sepolia Testnet". After this PR v3 is mainnet only, and the description is what llms.txt and search show.
   Fix: "Uniswap v4 contract addresses on Celo Mainnet and Celo Sepolia, and v3 addresses on Celo Mainnet".

Verified good

• ODIS endpoints: both new URLs return 200 on /status; the old cloudfunctions.net mainnet URL returns 404.
• ODIS keys and URLs: they match ODIS_MAINNET_CONTEXT_PNP and ODIS_CELO_SEPOLIA_CONTEXT_PNP in social-connect packages/identity/src/odis/query.ts, character for character. The PR uses the PNP keys, which is right for this phone-number page.
• Version claims: @celo/identity 6.0.0-beta.0 ships getServiceContext, OdisContextName.CELO_SEPOLIA and the Celo Sepolia contexts. 5.1.2 has getServiceContext but no Celo Sepolia context, so "5.1.2 has no Celo Sepolia context" is correct.
• Uniswap v3: the mainnet factory, SwapRouter02 and UniversalRouter have code on Celo mainnet and 0x on Celo Sepolia, so "no published Celo Sepolia deployment" holds for those addresses.
• Deleted page: attestation-service has a redirect; the two older redirects that landed on it now go straight to /contribute-to-celo/release-process; no other inbound references remain, and the nav entry and overview link are gone. No redirect chains.
• setup.mdx: the code already used the Sepolia RPC, so the prose now matches it.
• Remaining Alfajores mentions: I read all of them on this head. Apart from finding 1, they are history, notices or migration pages.

What the PR got right

Honest scoping: the caveats section names exactly the two things it could not verify. Replacing the dead ODIS table with values from the published source is the right fix, not just a rename. Deleting a runbook for a retired service, with redirects, is better than renaming networks inside it. This is one round of three targeted edits.

Merge-order hazards

docs.json redirects and nav are touched, so any PR editing those lines near release-process may need a rebase. #2353 adds redirects near the top of the list, so expect a trivial conflict if both are open. No other open PR touches these pages.

[palango]

All three are fixed in c927d24.

1. transaction-types.mdx now imports celoSepolia and uses it for both clients. I checked it with viem 2.55.10: createPublicClient({ chain: celoSepolia, transport: http() }).getChainId() returns 11142220 against the live RPC.
2. The Portal page has a <Warning> under the initialization examples. It says Portal's chain list does not yet name Celo Sepolia and that readers should confirm support with Portal. I haven't asked Portal yet.
3. The Uniswap description now reads "Uniswap v4 contract addresses on Celo Mainnet and Celo Sepolia, and v3 addresses on Celo Mainnet".

mint broken-links passes: "success no broken links found".

[GigaHierz]

head c927d24 · API head == refs/pull/2346 (asserted); 5 commits, 8 files; branch is 8 commits behind main and git merge-tree reports a docs.json conflict; mint broken-links --check-redirects: no broken links; scripts/check-orphans.sh: no orphan pages; CI (gh pr checks): broken-links pass, GitGuardian pass, StepSecurity pass, Mintlify Deployment skipping; mint dev: 6 changed pages rendered, console clean on settled load (first load of two code-heavy pages gave transient 500s while the dev server compiled; zero on reload), 3 attestation-service redirect paths return 307 to /contribute-to-celo/release-process

Verdict: REQUEST-CHANGES

Findings (severity-ordered)

1. MEDIUM · docs.json (redirects block, around lines 600-610 and the three retargeted redirects) · The branch is 8 commits behind main and does not merge cleanly: git merge-tree --write-tree origin/main HEAD reports CONFLICT (content): Merge conflict in docs.json (four commits on main touched docs.json since the merge base: #2350, #2353, #2351, #2361). Failure scenario: the PR is not mergeable as it stands, and a hurried resolution of the redirects array could drop either this PR's new /contribute-to-celo/release-process/attestation-service redirect or main's #2353 redirects, which would reintroduce a 404 on the removed page. Fix shape: rebase onto current main, resolve docs.json keeping both sets of redirects, then re-run mint broken-links --check-redirects and bash scripts/check-orphans.sh on the rebased head.

2. LOW · PR description "Caveats" (affects tooling/libraries-sdks/contractkit/odis.mdx lines ~41-46) · The description defers the ODIS auth example (WalletKeySigner taking contractKit, the 5.x API) as "left for later" with no filed issue. Failure scenario: per the review rules, deferred work that lives only in prose leaves the finding open, and the 6.0.0 release will silently break the example this PR just refreshed. Fix shape: file a follow-up issue for the 6.0.0 auth examples and link it from the PR description (or fix the example in this PR).

Status of my three earlier findings

• (1) transaction-types.mdx: FIXED. celoAlfajores replaced with celoSepolia in the import and both clients (diff d306f47..c927d24); the rendered page contains celoSepolia 3 times and celoAlfajores 0 times. celoSepolia is exported by viem 2.57.0 (chains/definitions/celoSepolia.ts, chains/index.ts); celoAlfajores there is marked @deprecated. The two remaining "Alfajores" strings on that page are forum links to the 2023 Gingerbread release (history, correct to keep).
• (2) Portal: RESOLVED with a caveat. I fetched docs.portalhq.io/resources/blockchain-support: it lists Celo mainnet (eip155:42220) and "Celo Alfajores Testnet" (eip155:44787), and no Celo Sepolia (the only Sepolia entries are other chains: Arbitrum, Base, Blast, Ethereum, Fraxtal, Linea, Optimism, Polynomial, Scroll). The new <Warning> after the gateway tabs says exactly that and tells readers to confirm with Portal. The warning is accurate and renders. Residual risk is that the five examples may not work until Portal adds support; the warning discloses it.
• (3) uniswap-contracts.mdx description: FIXED. Frontmatter now reads "Uniswap v4 contract addresses on Celo Mainnet and Celo Sepolia, and v3 addresses on Celo Mainnet", consistent with the <Info> box and the v3 table (mainnet column only, plus a line saying v3 has no published Celo Sepolia deployment).

Verified good

• Repo-wide grep for alfajores|44787|celoAlfajores outside docs.json redirect sources: remaining hits are all history or migration context (home/history.mdx, build-on-celo/index.mdx timeline, network-overview and celo-sepolia pages describing the replacement, ice-cream/isthmus upgrade activation records, the archived Sepolia launch notice, native-ETH-bridging note, migrate-node.mdx, self-agent-id retired-network note, AGENTS.md rule). No live instruction to use Alfajores remains. celoAlfajores appears nowhere. The 21 docs.json hits are redirect sources only.
• ODIS page: both combiner URLs answer HTTP 200 on /status. @celo/identity@6.0.0-beta.0 (npm pack) contains OdisContextName.CELO_SEPOLIA, getServiceContext, and the same URLs and public keys the page documents (mainnet key and Sepolia PNP key match character for character). 5.1.2 exists on npm, consistent with the "no Celo Sepolia context in 5.1.2" sentence.
• Attestation-service removal: nav entry, overview link and file removed together; no remaining inbound links to the deleted path except redirect sources; the two older redirects were retargeted directly (no chains); orphan check clean.
• setup.mdx prose change matches the Sepolia RPC already used in its code.

What the PR got right

• All three earlier findings were addressed in one small follow-up commit, and the Portal fix chose disclosure over an unverifiable claim.
• The description is candid about what could not be verified (Portal gateway, ODIS lookup), and those caveats match what I found.
• History pages were left alone, and the ODIS endpoints that were actually dead (cloudfunctions.net) were replaced rather than only renamed.

Merge-order hazards

• docs.json is the shared file: main moved four commits through it (#2350, #2351, #2353, #2361) and the conflict is already real. Rebase this PR first; its redirect retargets are order-insensitive.
• No other file in this PR overlaps files changed on main (merge-tree reports docs.json only).

[palango]

Both addressed.

1. Rebased onto current main. The docs.json conflict was only at the top of the redirects array, where main's new redirects and this PR's attestation-service redirect landed in the same spot. I kept all of main's redirects as they were and put the attestation-service redirect after them. The two retargeted redirects and the nav removal are unchanged. On the rebased head, git diff origin/main -- docs.json shows only this PR's four changes, mint broken-links --check-redirects reports no broken links, and scripts/check-orphans.sh reports no orphan pages.
2. Filed ODIS page: update the WalletKeySigner example for @celo/identity 6.0 #2365 for the WalletKeySigner example. In 6.0.0-beta.0 the signer takes a sign191 function instead of a ContractKit instance. npm latest is still 5.1.2, so changing the example now would break it for stable users. The issue lists what to change once 6.0.0 is released, and the PR description links it.

[GigaHierz]

head bbb6daa · API head == refs/pull/2346 (asserted after force re-fetch); 5 commits, 8 files; 4 commits behind main (a12466b, includes the home/ to learn/ move); git merge-tree --write-tree origin/main conflicts in tooling/libraries-sdks/contractkit/setup.mdx only (docs.json auto-merges now); on a temp merge into main: mint broken-links --check-redirects no broken links, bash scripts/check-orphans.sh no orphan pages; gh pr checks: broken-links pass, GitGuardian pass, StepSecurity pass, Mintlify Deployment skipping; ODIS combiners both 200 on /status; keys checked against @celo/identity@6.0.0-beta.0 from npm

Verdict: REQUEST-CHANGES

Status of earlier findings

• docs.json conflict with main: RESOLVED. The four commits that conflicted last time are no longer a problem; docs.json merges cleanly into current main (the /home/... to /learn/... renames and the attestation-service redirects coexist). The branch now has one new, different conflict (finding 1 below).
• ODIS 6.0 auth example deferred with no issue: RESOLVED. The description now links #2365, which is open, names the file and lines (odis.mdx prose line 41, code lines 43-48), quotes the 6.0 WalletKeySigner type, and says what to change when 6.0.0 becomes latest. I confirmed its premise: npm latest is 5.1.2, beta is 6.0.0-beta.0, and 6.0.0-beta.0 lib/odis/query.d.ts has sign191 and no contractKit field.
• (Earlier round) celoAlfajores in transaction-types, Portal caveat, Uniswap description: still fixed, see Verified good.

Findings

1. MEDIUM · tooling/libraries-sdks/contractkit/setup.mdx:52 · The branch no longer merges cleanly: main changed the same sentence in #2367 (the link now reads /learn/network/overview), this PR rewrites it to say Celo Sepolia while keeping the old /build-on-celo/network-overview link. Failure scenario: the PR cannot merge as it stands, and a "take mine" resolution reverts #2367's link fix while a "take main's" resolution brings back alfajores as the example network. Fix shape: rebase onto current main and keep both changes, i.e. In this example will use Celo Sepolia (you can read more about it [here](/learn/network/overview)). I resolved it that way in a temp merge and both link and orphan checks passed.

Verified good

• No live Alfajores instruction remains on a merge into current main. git grep -il 'alfajores\|44787' (excluding submodules) hits only: AGENTS.md:98 (the rule), self-agent-id.mdx:30 (retired-network note), build-on-celo/index.mdx and learn/history.mdx (dated history), learn/network/overview.mdx and tooling/testnets/celo-sepolia/index.mdx (the replacement and migration pages), native-ETH-bridging.mdx:9, learn/protocol/transactions/transaction-types.mdx:259,287 (forum links to the 2023 release), the archived notices and the Ice Cream / Isthmus activation tables. celoAlfajores appears nowhere. docs.json mentions Alfajores only in redirect sources.
• learn/protocol/transactions/transaction-types.mdx (moved by #2367) carries the celoSepolia fix through the rename; git applies it without conflict.
• ODIS page: both URLs return 200 {"version":"3.3.3"} on /status; the old cloudfunctions.net mainnet URL returns 404. The mainnet key and the Celo Sepolia PNP key in the table match ODIS_MAINNET_CONTEXT_PNP and ODIS_CELO_SEPOLIA_CONTEXT_PNP in @celo/identity@6.0.0-beta.0 character for character (grep count 1 per key in the page and in the package). 5.1.2 has getServiceContext but no Sepolia context, matching the page's sentence.
• Portal: the <Warning> after the gateway tabs says Portal's chain list does not name Celo Sepolia and tells the reader to confirm support; the five eip155:11142220 examples carry the right chain ID.
• Uniswap: frontmatter description and the <Info> box now agree that v3 is mainnet only; the v3 table has one network column; no Alfajores explorer links remain.
• Attestation-service removal: file, nav entry and overview link gone together; redirect source has no inbound page link; orphan check clean on the merge.
• Rendering with mint dev (merged tree): the six changed pages returned 200 with zero console errors and no horizontal scroll at 1280 and 412x915. Treat that as a smoke test only; the link, orphan and grep results above are from the files.

What the PR got right

All earlier findings were closed with a commit or a filed issue, and the issue is specific enough to act on without the PR. Replacing the dead ODIS endpoints with the values the published package ships, instead of only renaming the network, is the right fix. Deleting the runbook for a retired service with redirects, rather than renaming networks inside it, avoids shipping a procedure nobody can run. The caveats name exactly the two things the author could not verify.

Merge-order hazards

• Rebase onto main first; the only conflict is the one sentence in setup.mdx.
• #2368 (tooling to build/tools): git merge-tree of this branch against #2368's head conflicts on the same sentence in build/tools/libraries-sdks/contractkit/setup.mdx, so whichever of the two lands second repeats the resolution above (using whatever link main has then). Everything else merges cleanly, including docs.json.
• #2366 and #2369: both merge cleanly with this branch (git merge-tree of each pair is clean).

[palango]

Rebased onto main. The setup.mdx line now says "Celo Sepolia" and keeps the /learn/network/overview link from #2367. Nothing else conflicted, and none of the other links in this PR point at a moved path. mint validate, mint broken-links --check-redirects and the orphan check pass on the new head, and the Alfajores grep over .mdx returns the same history and migration pages you listed. I also fixed the count in the description (13 pages, not 14; migrate-node.mdx no longer exists) and added the transaction-types row that was missing from the table.

[GigaHierz]

head e4348a9 · API headRefOid == refs/remotes/pr/2346 after force re-fetch; 5 commits on a12466b, 8 files; git merge-tree --write-tree origin/main (7b8f97c, #2368) is clean, git follows the renames; on a trial merge into current main: mint broken-links --check-redirects no broken links, mint validate pass, scripts/check-orphans.sh no orphan pages; gh pr checks: broken-links, GitGuardian, StepSecurity pass, Mintlify Deployment skipping; ODIS /status on both combiners 200; keys compared to @celo/identity@6.0.0-beta.0 from npm pack

Verdict: REQUEST-CHANGES

Status of earlier findings

Earlier review was at bbb6daa (newest of three).

1. setup.mdx merge conflict with main (the sentence #2367 had changed): FIXED. At the new head the line reads "In this example will use Celo Sepolia (you can read more about it here)" (tooling/libraries-sdks/contractkit/setup.mdx:51), keeping #2367's link and the Sepolia wording. It still carries the old tooling/ path; see the layout section.
2. ODIS 6.0 auth example deferred with no issue: still RESOLVED. #2365 is open, names odis.mdx prose line 41 and code lines 43-48, quotes the 6.0.0-beta.0 WalletKeySigner type and says what to change when 6.0.0 becomes latest. npm dist-tags today: latest 5.1.2, beta 6.0.0-beta.0, so the premise holds.
3. Earlier-round items (celoAlfajores in transaction-types, Portal caveat, Uniswap description): still FIXED, see Verified good.

Findings

1. LOW · tooling/libraries-sdks/contractkit/odis.mdx:77-82 (build/tools/libraries-sdks/contractkit/odis.mdx after the move) · The PR adds a new code example, the getServiceContext(OdisContextName.CELO_SEPOLIA) snippet, but the body records no command or output for it, and the snippet does not show where OdisUtils comes from. AGENTS.md section 5: "Every example that stays must run. The PR that adds or changes one notes the command and its output", and "imports shown".
   • Scenario: a reader or agent copies the block into a file, gets OdisUtils is not defined, and nothing in the PR shows the snippet was ever executed against 6.0.0-beta.0. (Checked statically, not executed: the package's lib/index.js exports OdisUtils, OdisUtils.Query includes getServiceContext and OdisContextName with MAINNET = "mainnet" and CELO_SEPOLIA = "celo-sepolia", so the call shape is right.)
   • Fix shape: add import { OdisUtils } from "@celo/identity"; // 6.0.0-beta.0 as the first line of the block, run it against @celo/identity@6.0.0-beta.0, and paste the command and the printed odisUrl (https://odis-combiner.celo-sepolia.celo-testnet.org) into the PR body under Verification.

Layout move (#2368): rebase needed, no manual conflict

• git merge-tree --write-tree --name-only origin/main refs/remotes/pr/2346 returns a clean tree. No conflicting files, including docs.json (the new redirect and the two retargeted redirects merge by hunk).
• The author should still rebase so the branch shows the new paths. Edited files and where they now live:
  • tooling/libraries-sdks/contractkit/odis.mdx -> build/tools/libraries-sdks/contractkit/odis.mdx
  • tooling/libraries-sdks/contractkit/setup.mdx -> build/tools/libraries-sdks/contractkit/setup.mdx
  • tooling/contracts/uniswap-contracts.mdx -> build/tools/contracts/uniswap-contracts.mdx
  • tooling/libraries-sdks/portal/index.mdx -> build/tools/libraries-sdks/portal/index.mdx
  • learn/protocol/transactions/transaction-types.mdx, contribute-to-celo/release-process/index.mdx, contribute-to-celo/release-process/attestation-service.mdx (deleted), docs.json: paths unchanged.
• Nothing to hand-resolve; the PR adds no links to moved paths. The body table and the "Left for later" paragraph name tooling/... paths, so update those to build/tools/... after the rebase.

Verified good

• No live Alfajores instruction on the trial merge. Case-insensitive search for alfajores and 44787 across the repo (excluding submodules) hits only: AGENTS.md (the rule), build/agents/self-agent-id.mdx:30 (retired-network note), build/index.mdx:55-57 and learn/history.mdx (dated history), learn/network/overview.mdx and build/tools/testnets/celo-sepolia/index.mdx (replacement and migration pages), learn/bridged-tokens/native-ETH-bridging.mdx:9, learn/protocol/transactions/transaction-types.mdx:259,287 (2023 forum links), four archived notices, the Ice Cream and Isthmus activation tables, and redirect sources in docs.json. celoAlfajores appears nowhere. That is 13 .mdx pages, matching the body.
• ODIS: https://odis-combiner-mainnet.rc1-europe-west1.celo-testnet.org/status and https://odis-combiner.celo-sepolia.celo-testnet.org/status both return 200 {"version":"3.3.3"}; the old us-central1-celo-pgpnp-mainnet.cloudfunctions.net returns 404. The mainnet key and the Celo Sepolia key in the page each appear once in the page and in ODIS_MAINNET_CONTEXT_PNP / ODIS_CELO_SEPOLIA_CONTEXT_PNP of @celo/identity@6.0.0-beta.0 (string-exact match). The 5.1.2 tarball has getServiceContext and no Celo Sepolia context, matching the page's sentence, and its mainnet URL equals the page's. The identifier lookup itself was not run (needs an account with ODIS quota), as the body says.
• Portal: docs.portalhq.io/resources/blockchain-support still lists only eip155:42220 for Celo plus "Celo Alfajores Testnet (eip155:44787)"; the <Warning> and the body caveat are accurate. The five eip155:11142220 examples carry the right chain ID (0xaa044c = 11142220 on forno Celo Sepolia).
• Uniswap: eth_getCode on the Celo Sepolia RPC for the v3 factory mainnet address returns 0x; Uniswap's v3 Celo deployment page has a CELO and an Alfajores column only and no Sepolia. Frontmatter description and the <Info> box agree (v4 on mainnet and Celo Sepolia, v3 mainnet only); the v3 table has one network column.
• Attestation-service removal: file, nav entry and the overview link are gone together. Redirect sources /contribute-to-celo/release-process/attestation-service, /community/release-process/attestation-service and /what-is-celo/joining-celo/contributors/release-process/attestation-service all point at /contribute-to-celo/release-process (final page, no chain); /validator-guide/attestation-service already pointed elsewhere. No .mdx links to the deleted path remain.
• Closes #2290: the issue's definition of done is met. The search leaves only the listed out-of-scope pages, Sepolia values for ODIS and Uniswap were checked against the live service and chain, and broken-links is green.
• Frontmatter on edited pages is unchanged and has title and description.
• Smoke render on the trial merge: the six changed pages return 200, the old attestation-service paths 307 to /contribute-to-celo/release-process, no horizontal scroll, no console errors on the ODIS page. Smoke test only.

What the PR got right

Replacing the dead ODIS endpoints with the values the published package ships (not just renaming the network), deleting the runbook for a retired service with redirects instead of renaming networks inside it, and writing caveats that name exactly what could not be verified (Portal chain list, ODIS identifier lookup). The deferral of the 6.0 auth example is tracked in a specific issue. The only remaining gap is the run record for one new snippet.

Merge-order hazards

• Against #2368 (already on main): clean merge, nothing to resolve; rebase for tidy paths and update the body paths.
• Pairwise git merge-tree of this branch with #2355 and with #2357: both clean. Order among the three does not matter for this PR.
• Observation, not counted against this PR: uniswap-contracts.mdx still lists partner (Uniswap) contract addresses, which AGENTS.md "Partner contract addresses" says to replace with a link to the provider's page. That predates this PR and is a separate cleanup.

[palango]

Rebased onto main, so the edited pages now sit under build/tools/.... The rebase was clean, and the description uses the new paths.

The ODIS snippet now starts with import { OdisUtils } from "@celo/identity";, and an install line, npm install @celo/identity@6.0.0-beta.0 viem, sits right above it, because a plain install gets 5.1.2 and the beta needs viem alongside it (9354117). I ran it with Node 24 after that install, and it printed https://odis-combiner.celo-sepolia.celo-testnet.org for CELO_SEPOLIA and the mainnet combiner URL for MAINNET. The command and output are in the description under Verification.

mint validate, mint broken-links --check-redirects and the orphan check pass on the new head.

[GigaHierz]

head 9354117 · API headRefOid == refs/remotes/pr/2346 after force re-fetch; 6 commits on origin/main 7f5d9bb, 8 files; git merge-tree --write-tree origin/main clean (no conflicts); mint broken-links --check-redirects no broken links, mint validate pass, scripts/check-orphans.sh no orphan pages; gh pr checks: broken-links, GitGuardian, StepSecurity pass, Mintlify Deployment skipping; ODIS snippet run in a clean directory: Celo Sepolia URL https://odis-combiner.celo-sepolia.celo-testnet.org, mainnet URL https://odis-combiner-mainnet.rc1-europe-west1.celo-testnet.org

Verdict: APPROVE

Status of earlier findings

1. New getServiceContext(OdisContextName.CELO_SEPOLIA) snippet had no import and no recorded command or output: FIXED. The block now starts with import { OdisUtils } from "@celo/identity"; and an install line npm install @celo/identity@6.0.0-beta.0 viem sits directly above it (build/tools/libraries-sdks/contractkit/odis.mdx, after the key tables). The PR body has a Verification entry with the command and the two printed URLs. I reran it independently (details under Verified good) and the output matches the body.
2. Old tooling/... paths in the body: FIXED. The body table and the verification list use build/tools/...; the branch is rebased and the edited pages sit under build/tools/.
3. Earlier rounds (setup.mdx conflict, ODIS 6.0 auth example tracked, celoAlfajores in transaction-types, Portal caveat, Uniswap description): still FIXED, see Verified good.

No new findings.

Verified good

• ODIS snippet, run outside the repo (/tmp, Node 20.19.4, so the page's TypeScript block was saved as .mjs; the code is valid JS as written): npm install @celo/identity@6.0.0-beta.0 viem then getServiceContext(OdisContextName.CELO_SEPOLIA).odisUrl prints https://odis-combiner.celo-sepolia.celo-testnet.org and MAINNET prints https://odis-combiner-mainnet.rc1-europe-west1.celo-testnet.org. Both match the page's URL table. The odisPubKey values the package prints for Celo Sepolia (kPoRxWdE...) and mainnet (FvreHfLm...) match the page's key table character for character.
• The install line is needed in both halves: a plain npm install @celo/identity resolves to 5.1.2, where OdisContextName.CELO_SEPOLIA does not exist and getServiceContext(...) silently returns the mainnet URL and key (observed: both lines print the mainnet combiner). @celo/identity@6.0.0-beta.0 without viem fails at import with Cannot find module 'viem' from @celo/phone-number-privacy-common. The page's 5.1.2 sentence is accurate.
• No live Alfajores instruction. Case-insensitive search for alfajores and 44787 in the .mdx files gives the same 13 pages the body lists (history, migration notes, the Celo Sepolia replacement pages, archived notices and upgrade tables). celoAlfajores and cloudfunctions.net appear in no .mdx file. celoSepolia is exported by viem/chains in the installed viem.
• ODIS URLs: mainnet /status returns 200 {"version":"3.3.3"}; Celo Sepolia /status returned 503 (envoy "remote connection failure") on my first four attempts and then 200 {"version":"3.3.3"} a few minutes later. The old us-central1-celo-pgpnp-mainnet.cloudfunctions.net returns 404.
• Portal: docs.portalhq.io/resources/blockchain-support still lists Celo as eip155:42220 plus "Celo Alfajores Testnet" only, so the <Warning> and the body caveat are accurate. eip155:11142220 is the right Celo Sepolia ID (eth_chainId on forno Celo Sepolia returns 0xaa044c).
• Uniswap: eth_getCode for the v3 factory address on Celo Sepolia returns 0x; the frontmatter description, the <Info> box and the single-network v3 table agree.
• Attestation-service removal: file, nav entry and the overview link are gone together. Redirect sources /contribute-to-celo/release-process/attestation-service, /community/release-process/attestation-service and /what-is-celo/joining-celo/contributors/release-process/attestation-service all point at /contribute-to-celo/release-process (final page, no chain). On a freshly started mint dev (port 3711) all three return 307 to /contribute-to-celo/release-process.
• Issue #2365 is still open and still tracks the 6.0 WalletKeySigner/sign191 example; the page still has the 5.x contractKit example (odis.mdx lines 41 and 46), so the premise holds.
• AGENTS.md: frontmatter unchanged and has title and description on every edited page; bare bash and ts fences; no emoji or promotional wording added; links root-relative.
• Rendering (smoke test only): the ODIS, setup, Uniswap, Portal, transaction-types and release-process pages return 200 on port 3711; the ODIS page shows the Celo Sepolia URL, the install line and no Alfajores text, no horizontal scroll, no console errors. My first mint dev served a stale docs.json from the shared cache (the new redirect returned 404 and /community/... pointed at the old destination); after restarting my own server the content and redirects are the PR's.

What the PR got right

Replaced the dead ODIS endpoints with the values the published package ships rather than only renaming the network, removed the runbook for a retired service with redirects that point straight at the final page, wrote caveats naming exactly what could not be verified (Portal chain list, ODIS identifier lookup), tracked the 6.0 auth change in a specific issue, and answered the snippet finding with an install line that is demonstrably necessary plus a recorded run.

Merge-order hazards

• Clean against current main. Pairwise with #2355 (touches only build/tools/wallets/metamask/use.mdx): no shared files, order does not matter.
• Housekeeping, not counted: #2365 still names the old path tooling/libraries-sdks/contractkit/odis.mdx; its content is otherwise right. The fix goes in whenever 6.0.0 ships as latest.
• Observation, not counted: uniswap-contracts.mdx still lists partner contract addresses, which AGENTS.md "Partner contract addresses" says to replace with a link; it predates this PR.