[Anirudh-712]

Fixes #136.

Searching for a TEX address returns not found. For the ZIP 320 example, GET https://api.zecblock.com/api/address/tex1s2rt77ggv6q989lr49rkgzmh5slsksa9khdgte returns 404 {"error":"Invalid transparent address"} (19 Oct 2026, 05:17 UTC). Its P2PKH form, t1VmmGiyjVNeCjxDZzg7vZmd99WyzVby9yC, returns 200.

A TEX address is the 20-byte P2PKH key hash re-encoded as Bech32m with the HRP tex (textest on testnet). Payments to it are ordinary P2PKH outputs, so its history is the t-address history (ZIP 320, Specification). ZIP 320 asks every consumer of Zcash addresses to support it.

Changes

• server/api/lib/zcash-address.js: texToTransparentAddress() decodes Bech32m with the bech32 package the API already uses. It checks the HRP and the 20-byte length, then re-encodes Base58Check with lead bytes 0x1CB8 (t1) or 0x1D25 (tm), as in the ZIP 320 reference code. It returns null for a bad checksum, another HRP, a payload that is not 20 bytes, mixed case, or a Bech32 (not Bech32m) checksum.
• server/api/routes/address.js: /api/address/:address and /api/address/:address/graph look up the t-address for tex1... and textest1.... The response keeps the TEX string as address, so the page's data.address !== address check still matches, and adds transparentAddress. An invalid TEX string returns 404 Invalid TEX address. /v1/addresses/:address passes through as before.
• lib/zcash.ts, the address page.tsx and layout.tsx: detectAddressType returns tex for those prefixes, so search goes to /address/tex1.... Both isValidAddressSyntax copies accept the 38-character data part. The header reads "TEX form (ZIP 320) of transparent address t1..." and links that page.

Please check

• TEX pages are noindex, follow. They repeat the t-address page, which stays the indexed copy. A canonical link to the t-address page would be a one-line change in generateMetadata if you prefer that.
• New visible copy: "TEX form (ZIP 320) of transparent address ... Both forms share one balance and history."
• All-uppercase TEX strings are still rejected, as UA and Sapling strings are today.

Tests

• server/api/test/zcash-address.test.js: three mainnet pairs from zcash-test-vectors zip_0320.json, the testnet pair from librustzcash's tex_testnet test, and the five rejection cases.
• server/tests/address-pagination.test.js: a TEX request returns the P2PKH summary, page and graph, every query uses the t-address, and invalid TEX strings return 404.
• server/tests/address-pagination-client.test.js: detectAddressType for both HRPs, and the layout links the t-address and sets index: false.

I ran these red, then green, with Node's test runner. I did not run npm ci, so bech32, express, zod, react and react-dom were local stand-ins. All 15 zip_0320.json pairs also map correctly in a scratch run. tsc --noEmit, ESLint, next build and the route-cache build did not run here. CI runs them.

The WASM zcash_address decoder only exposes decode_unified_address, so TEX does not go through it. Using it would need a WASM rebuild.

🤖 Generated with Claude Code

[vercel]

@Anirudh-712 is attempting to deploy a commit to the kenbak's projects Team on Vercel.

A member of the Team first needs to authorize it.