Context
While researching SF-1 (Hardhat workspace) for reference-implementations, we noticed the ERC-3643/T-REX upstream story is easy to misread:
| Surface |
Status |
| ERC-3643/ERC-3643 |
Active — canonical maintained repo |
@erc3643org/erc-3643 |
Active npm — published from org repo |
@tokenysolutions/[email protected] |
Legacy npm — last release under old package name |
| TokenySolutions/T-REX |
Deprecated — redirects to ERC-3643 org |
The adapter implementation appears technically correct (source repo column points at ERC-3643/ERC-3643; ABI headers note verification against org repo main). The confusion is that the Pinned version column only lists legacy @tokenysolutions/[email protected], which readers (including downstream RI contract-setup work) can misinterpret as "track the deprecated Tokeny repo."
What is NOT wrong today
packages/adapter-evm-core/src/erc3643/abi.ts — Source repo column is github.com/ERC-3643/ERC-3643; signatures verified against org repo main (2026-06-01).
packages/adapter-evm-core/src/irs/abis.ts — same pattern.
packages/adapter-evm/CHANGELOG.md 2.1.0 — Source column is ERC-3643/ERC-3643.
packages/adapter-evm-core/README.md — links org repo in parentheses next to legacy npm pin.
Suggested documentation improvements
- Provenance tables (
abi.ts headers, CHANGELOG, adapter-evm-core README): add a short note that @tokenysolutions/[email protected] is the legacy npm artifact pin at ship time, not the repo to track, and mention @erc3643org/erc-3643 as the org-published successor npm package.
- ABI refresh procedure (
adapter-evm-core/README.md): prefer verifying against ERC-3643/ERC-3643 tags/releases; evaluate @erc3643org/erc-3643 before staying on legacy npm.
- Optional follow-up (separate PR): run ABI gate against
@erc3643org/[email protected] and update pinned npm references if bytecode/interface parity holds.
Downstream impact
reference-implementations SF-2 (upstream pinning + ABI compatibility gate) needs an unambiguous canonical upstream. RI docs were updated to point at ERC-3643/ERC-3643; adapter doc clarity would prevent future misreads.
Labels
documentation, erc-3643, ri-tokenized-deposits
Context
While researching SF-1 (Hardhat workspace) for
reference-implementations, we noticed the ERC-3643/T-REX upstream story is easy to misread:@erc3643org/erc-3643@tokenysolutions/[email protected]The adapter implementation appears technically correct (source repo column points at ERC-3643/ERC-3643; ABI headers note verification against org repo
main). The confusion is that the Pinned version column only lists legacy@tokenysolutions/[email protected], which readers (including downstream RI contract-setup work) can misinterpret as "track the deprecated Tokeny repo."What is NOT wrong today
packages/adapter-evm-core/src/erc3643/abi.ts— Source repo column isgithub.com/ERC-3643/ERC-3643; signatures verified against org repomain(2026-06-01).packages/adapter-evm-core/src/irs/abis.ts— same pattern.packages/adapter-evm/CHANGELOG.md2.1.0 — Source column is ERC-3643/ERC-3643.packages/adapter-evm-core/README.md— links org repo in parentheses next to legacy npm pin.Suggested documentation improvements
abi.tsheaders, CHANGELOG, adapter-evm-core README): add a short note that@tokenysolutions/[email protected]is the legacy npm artifact pin at ship time, not the repo to track, and mention@erc3643org/erc-3643as the org-published successor npm package.adapter-evm-core/README.md): prefer verifying against ERC-3643/ERC-3643 tags/releases; evaluate@erc3643org/erc-3643before staying on legacy npm.@erc3643org/[email protected]and update pinned npm references if bytecode/interface parity holds.Downstream impact
reference-implementationsSF-2 (upstream pinning + ABI compatibility gate) needs an unambiguous canonical upstream. RI docs were updated to point at ERC-3643/ERC-3643; adapter doc clarity would prevent future misreads.Labels
documentation, erc-3643, ri-tokenized-deposits