docs: add a chain and package compatibility matrix

[Annoor24]

Overview

There was no single place that said which Wraith SDK entry point, framework package versions, contract versions, and on-chain deployment IDs belong together. The per-chain contracts pages, the SDK overview and the Stellar network reference each held one slice of the answer, so readers had to infer the combinations themselves. reference/compatibility-matrix.mdx now publishes that matrix for EVM, Stellar, Solana and CKB: the SDK core version pins, the Chain enum value and entry point for each chain, the curve and optional peer dependency each entry point needs, the deployed identifiers, and a per-chain migration-notes section. Every row links to the page that owns its deployment IDs and to the migration guidance for that chain, and a new CI check keeps the matrix from drifting from the deployment references it transcribes.

Related Issue

Changes

[ADD] reference/compatibility-matrix.mdx

• SDK-core table pinning @wraith-protocol/sdk ^1.4.5 and the @noble/curves, @noble/hashes and viem dependency roles.
• Chain matrix row per chain (EVM, Stellar, Solana, CKB): Chain enum value, SDK entry point, curve, framework/peer packages, and links to that chain's deployment IDs and migration notes.
• Deployment ID tables per chain, transcribed from the owning pages: the four Horizen Testnet EVM addresses, the two live Stellar Testnet contract strkeys (announcer v2, names v1) with the pending registry/sender called out, the Solana devnet deploy command, and the CKB testnet code hash plus deployment cell-dep transaction hash.
• Per-chain migration notes (EVM deploy order and constructor arg; Stellar quarterly testnet resets and v2 event topics; Solana PDA/rent and program-ID pinning; CKB code-hash rotation and no peer dependency) plus a known-gaps table.

[ADD] scripts/check-compatibility-matrix.mjs

• Extracts every EVM address, CKB code/transaction hash and Stellar contract strkey from the matrix page and fails if one is not also present in contracts/*.mdx, reference/stellar-networks.mdx or the sdk/chains/*.mdx primitives pages, so a matrix row cannot disagree with the deployment reference that owns it.

[MODIFY] docs.json

• Registers reference/compatibility-matrix in the Reference navigation group.

[MODIFY] package.json

• Adds check:compatibility-matrix and includes it in npm test alongside check:snippets and check:nav-coverage.

Verification Results

API-only: files fetched, edited, committed and pushed through the GitHub Contents/Git API (no clone).
Both docs checks were executed locally with Node 24 against a mirror of the page tree
assembled from the API:
  $ node scripts/check-nav-coverage.mjs
  Nav coverage passed: 71 pages checked, 71 nav entries verified.
  $ node scripts/check-compatibility-matrix.mjs
  Compatibility matrix passed: 8 deployment identifiers verified against 9 source pages.
The 8 identifiers are the 4 Horizen EVM addresses, the 2 live Stellar contract strkeys and the
2 CKB testnet hashes; `docs.json` and `package.json` were re-parsed after editing.
Not run here: `npm run check:snippets` and `mint validate` (no dependency install in this
environment). The new page adds no ts/tsx/js fences, so it contributes nothing for the snippet
checker to compile.

Acceptance Criteria	Status
Publish a table for EVM, Stellar, Solana, and CKB	Done - one chain matrix row per chain plus a deployment table per chain
Include SDK core and framework packages	Done - SDK core table with version pins, and curve + peer/framework packages per chain row
Link each row to deployment IDs and migration notes	Done - every chain row links to its deployment-ID section and its migration-notes section
Keep the matrix validated against the deployment manifest	Done - scripts/check-compatibility-matrix.mjs cross-checks every identifier in the page against the deployment reference that owns it, and runs in npm test

Closes #155

[drips-wave]

@Annoor24 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[truthixify]

The matrix is useful, but the checker concatenates every source page and only proves each ID appears somewhere. A value under the wrong chain or contract still passes. Please compare each row to its owning manifest entry, including its version.

[truthixify]

The conflict resolution did not fix the checker. It still combines every source page and only checks whether an ID appears anywhere. Please validate each chain, contract, and version against its owning manifest entry.

[Annoor24]

@truthixify Reworked the checker so it validates each row against its owning entry, and resolved the merge conflict.

scripts/check-compatibility-matrix.mjs (rewritten)

It no longer concatenates the source pages and greps for an ID. Each chain section now has a named owner, and every row is resolved to its contract's entry in that owner:

• EVM → contracts/evm.mdx (the Deployed Addresses (Horizen Testnet) table)
• Stellar → scripts/contract-registry.json (networks["stellar-testnet"] — address and version)
• CKB → contracts/ckb.mdx (each script's Deployed Code Hash / Cell Dep)
• Solana → contracts/solana.mdx (no program IDs published)

It fails when a row's contract has no owning entry, when the value is not that contract's value, when the value belongs to a different chain or contract, when the version does not match the registry, or when the owner publishes a value but the matrix marks the row pending. It also builds a global identifier → (chain, contract) index, so a value placed under the wrong chain or contract is caught rather than passing because it appears somewhere.

What the stricter check caught (and I fixed)

Run against the previous page, it flagged the CKB table: wraith-stealth-lock was publishing 0xc133817d…, which contracts/ckb.mdx owns under wraith-names-type — the stealth-lock code hash is not recorded in the deployment reference (it is still stealthLockCodeHash: "0x…"). I corrected that row to Not published in these docs and relabeled the generic Deployment cell dep row to wraith-names-type cell dep, since that hash is the names-type cell dep in the owner. No other value changed.

$ node scripts/check-compatibility-matrix.mjs
Compatibility matrix passed: 14 rows / 8 deployment identifiers validated against their owning entries

I also confirmed it now rejects the two failure modes you named — a value under the wrong chain (belongs to the evm chain (ERC5564Announcer), not Stellar) and a version drift (version is "v9", but scripts/contract-registry.json records "v1").

Conflict resolved

dirty → mergeable: true. Merged develop (f90797e2) into the branch as 50d30b42. The conflicts were docs.json and package.json, where develop added the placeholder and redirect checks; the merge keeps develop's check:placeholders / redirect scripts and the reference/stellar-event-schemas nav entry, and adds check:compatibility-matrix plus its nav entry, with npm test running both. CI will re-run on the new head.