OpenZeppelin / OpenZeppelin/openzeppelin-adapters
Clarify ERC-3643 upstream provenance: canonical repo vs legacy npm package
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 2
- Forks
- 1
- Avg merge
- 1h 47m
- Merged PRs (30d)
- 14
Description
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/t-rex@4.1.6 |
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/t-rex@4.1.6, 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
- Provenance tables (
abi.tsheaders, CHANGELOG, adapter-evm-core README): add a short note that@tokenysolutions/t-rex@4.1.6is the legacy npm artifact pin at ship time, not the repo to track, and mention@erc3643org/erc-3643as 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-3643before staying on legacy npm. - Optional follow-up (separate PR): run ABI gate against
@erc3643org/erc-3643@4.1.3and 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
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Review the provenance tables and ABI headers in packages/adapter-evm-core/src/erc3643/abi.ts and packages/adapter-evm-core/src/irs/abis.ts, plus adapter-evm/CHANGELOG.md and packages/adapter-evm-core/README.md. Clarify that @tokenysolutions/t-rex@4.1.6 is a legacy artifact pin, identify ERC-3643/ERC-3643 as canonical, and mention the successor npm package. Keep the ABI refresh and pin update as a separate follow-up.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- blockchain, documentation
- Issue type
- Documentation
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 72/100