Proposal: Establish criteria for deprecating and removing unmaintained wallets

[web3iocore]

Proposal: Establish criteria for deprecating and removing unmaintained wallets

Background

Based on recent user feedback, several integrated wallets have become unusable — their core functionality no longer works within the adapter. Today we have no formal standard for deciding when a broken wallet should be removed, so these dead integrations linger, degrade the user experience, and add maintenance burden.

This issue proposes a clear, objective policy for deprecating and delisting a wallet.

Problem

• Some wallets currently ship in the adapter but have broken core functionality.
• Without an agreed-upon rule, removal decisions are ad hoc and inconsistent.
• Keeping non-functional wallets listed misleads users and erodes trust in the adapter.

Proposal: Wallet Removal Criteria

A wallet becomes a candidate for removal when all of the following conditions are met:

1. Core functionality is broken — one or more essential capabilities (e.g. connect, sign transaction, sign message) do not work.
2. The failure persists for at least 3 consecutive days — it is not a transient outage.
3. The wallet's project team has been contacted — a report/issue was raised with them (or their designated channel).
4. No response and no resolution — the team has neither replied nor fixed the problem within the window.

When all four are satisfied, the wallet may be scheduled for delisting.

Definition of "core functionality"

For the purpose of this policy, core functionality includes at minimum:

• Establishing a connection / authorization
• Signing a transaction
• Signing a message
• (add any other capabilities the adapter treats as mandatory)

A wallet is considered "broken" if any of these fail consistently.

Suggested process

1. Detect & log — confirm the breakage and record the first-failure date.
2. Reproduce — verify it's reproducible and not an environment/config issue on our side.
3. Notify the wallet team — open a report on their side and record the contact date + channel.
4. Observe (≥3 days) — track whether it's fixed or acknowledged.
5. Announce deprecation — if criteria are met, mark the wallet as deprecated and give advance notice (proposed grace period: 1 week) to users.
6. Remove — delist the wallet from the adapter and note it in the changelog/release notes.

Acceptance criteria

• The removal criteria above are agreed upon and documented.
• A lightweight checklist/template exists for tracking a wallet through the process.
• The currently-broken wallets are evaluated against this policy.

[zorro11639]

I have a suggestions regarding this proposal about re-enabling restored wallets.

Once a wallet team resolves their issues, they should be able to submit a reinstatement issue in this repository. If the latest version passes standard functional checks, the NPM package can be republished and reintegrated.

[web3iocore]

That's a good suggestion. I agree that we should have a clear path for wallets to be re-listed after they've been fixed.

We can include a reinstatement process in the policy. Once the wallet team submits a reinstatement request, we'll verify that the latest version passes the required functional checks (e.g. connect, sign transaction, sign message). If everything works as expected, the wallet can be republished and re-integrated into the adapter.

This will ensure the process is transparent and consistent for all wallet providers.

[iweb3Nomad]

The 6-step process is a solid frame. A couple of things I think are worth talking through so the criteria hold up in practice:

What counts as "broken", and who confirms it?
Is one reproducible report enough, or do we want a few independent confirmations / a tracking issue before the clock starts? And is it judged manually or can we lean on some automated smoke check? Step 1 is probably where most cases will actually stall, so it'd be good to pin this down.

Should "deprecate" and "remove" be two distinct states in code?
Not just as steps in the timeline — I mean a deprecated adapter that still exports and just logs a warning (so downstream builds don't break), vs. actual removal which is the breaking change done later on a normal release. Worth spelling that out so "deprecated" isn't only an announcement.

[web3iocore]

Thanks for the thoughtful feedback. I agree these two points should be clarified.

For "Broken", the intention isn't to rely on a single source. Reports can come from multiple channels, including community developer feedback, issues reported by users, or problems discovered during our own testing. Before the observation window starts, we'll always verify that the issue is reproducible and confirm that it isn't caused by our side (e.g. adapter implementation or environment). So the decision is based on collected evidence plus maintainer verification, rather than a single report.

Regarding Deprecated vs Removed, our intention is to treat them as two distinct states:

Deprecated means the wallet adapter package is marked as deprecated on npm, with clear notices in the documentation and official website.
Removed is the complete delisting process. The adapter will no longer be included in the main adapter package, and its GitHub code will be moved into a dedicated deprecated directory for archival purposes. The official website will also clearly indicate that the wallet has been deprecated/removed.

[Benson0224]

I think the proposed criteria are generally clear and helpful. I have two questions/suggestions that may be worth clarifying further:

First, should we distinguish between a wallet team that is completely unresponsive and a wallet team that has acknowledged the issue and is actively working on a fix?

For example, if a wallet team replies within the observation window, confirms that the issue is reproducible, and provides a fix plan or timeline, but the final release takes more than three days due to reasons such as extension review, app store review, or internal release processes, should the wallet still be treated the same as an unmaintained or unresponsive wallet?

It may be more fair to separate these cases:

• No response and no fix within the window: proceed with deprecation/removal.
• Acknowledged and actively being fixed: extend the observation period or keep the wallet in a deprecated/warning state until the fix is verified.

This would help avoid removing wallets that are still actively maintained but need more time to ship a fix.

Second, should we maintain a more explicit checklist for “core functionality”?

The current examples — connection/authorization, signing a transaction, and signing a message — are a good baseline. However, as the adapter evolves, the required functionality may expand or differ across wallet types and platforms. A formal checklist could make the policy easier to apply consistently.

For example, the checklist could define:

• Required capabilities for all wallets
• Optional capabilities
• Platform-specific requirements, if any
• Supported test environments
• What counts as a consistent failure

This would make future removal decisions more objective and easier for both maintainers and wallet teams to follow.

[AndyBitBit]

Strongly support ! Establishing a clear, objective policy for deprecating and removing unmaintained wallets is a necessary step toward improving the adapter's reliability. Leaving non-functional integrations in the repository degrades the user experience and creates unnecessary technical debt for maintainers who have to carry dead code.

The proposed criteria and timeline strike the right balance between decisiveness and fairness. Requiring a reproducible failure in core functionality ensures that we only act on genuine breakages, while the 3-day observation window and mandatory outreach give wallet teams a fair opportunity to respond or deploy a fix before any action is taken.

Implementing this structured, five-step process will bring needed consistency to our release management. It protects users from broken workflows, sets clear expectations for external project teams, and ensures our maintenance efforts are focused on integrations that provide actual value.

[Murphytron]

Thanks for putting this proposal together! I strongly support this initiative.

Looking at the great suggestions already mentioned regarding re-integration, technical states, and handling responsive teams, I’d love to add a perspective from the DApp developer and end-user psychology side.

When a user tries to connect an unmaintained wallet and experiences a silent failure, they rarely assume the specific wallet is broken—they almost always assume the DApp itself is buggy or the network is lagging. By implementing this formal pruning process, we aren't just reducing maintenance debt; we are actively protecting the user retention rates and perceived reliability of every single DApp built on the TRON ecosystem.

Regarding Step 5 (Announce deprecation) and the proposed 1-week grace period, I have a quick UX-related question:
Do we plan to surface this "deprecated" state visually to the end-users in the adapter's UI modal? For example, adding a small Deprecated or Unstable badge next to the wallet icon during that final week? Or will the deprecation announcement remain strictly at the developer level (e.g., GitHub releases, changelogs, and console.warn) before the hard removal?
Either approach is fine, just wondering what the visual experience would be during that transition window. Awesome work structuring this out!

[kfd99m2frs-ui]

Thank you for putting together this proposal – it’s a necessary foundation for the long‑term health of the adapter. I’d like to add a few points for further discussion:

1. Automated health checks

Step 1 (“Detection & Documentation”) currently relies on manual effort. As more wallets are integrated, this won’t scale well. Could we consider adding automated smoke tests in CI (e.g., run daily against connection, signing, and other core functions)? If a wallet fails consistently for a certain number of days (e.g., the 3‑day threshold), an automated tracking issue could be created, and then a maintainer would confirm manually. This would reduce the maintenance burden and give the “3‑day” timeline an objective, data‑backed foundation.

2. UI visibility for deprecated wallets

Regarding Step 5 (“Announce Deprecation”), the proposal currently mentions only GitHub and changelog notifications. Some participants have already asked whether the deprecated status should be shown in the UI. I’d suggest adding visual indicators in the adapter’s wallet list (e.g., greyed‑out icons, a “removal pending” badge) and, when a user attempts to connect, outputting a clear console warning with a recommendation for an alternative wallet. This would make the change visible to end‑users (not just developers) and prevent confusion when the wallet is eventually removed.

3. Emergency removal for security vulnerabilities

The 3‑day observation window plus a 1‑week grace period is reasonable for most cases. However, if a wallet is found to have a serious security flaw (e.g., private key exposure), should we consider shortening or even skipping the grace period to allow maintainers to remove it urgently? I’d suggest adding an “emergency removal” clause to the standard process, with clear trigger conditions and an approval path.

These are my thoughts – I hope they help refine the proposal. Thanks again to the maintainers for driving this work.

[CooperDepp]

Thanks for formalizing this! I completely agree with the need for a strict, objective cleanup policy.

Adding to the excellent points already made about project management and UX, I want to highlight another massive hidden benefit of this proposal: Frontend Performance and Bundle Size.

As the TRON ecosystem expands and the adapter supports dozens of wallets, keeping unmaintained ones means every DApp in the ecosystem is forced to ship dead code. This includes unnecessary UI assets (like SVG/Base64 icons) and potentially obsolete third-party wallet SDKs. Proactively pruning these dead integrations is essentially a continuous optimization process, ensuring that the @tronweb3 packages remain lightweight, fast, and modern for DApp developers.
Regarding Step 6 (Remove), I just have a quick technical question about the cleanup depth:

When a wallet is scheduled for complete removal, is the plan to also aggressively purge all of its associated static assets (like logos) and remove any wallet-specific sub-dependencies from the repo's package.json to maximize bundle size reduction?

(I assume the answer is yes, but just curious about how thorough the actual cleanup PRs will be!) Awesome initiative overall!