Problem
SHKeeper currently supports a fixed set of ERC20 tokens (USDT, USDC) on the EVM-compatible chains it already integrates (Ethereum, BNB Chain, Polygon, Avalanche, Tron). There is no way for a user to add an arbitrary ERC20 token by simply providing its contract address.
This means that merchants who need to accept payments in other widely-used ERC20 tokens — such as DAI, WBTC, LINK, UNI, or any project-specific token — cannot do so without modifications to the codebase and a new release.
Proposed Solution
Allow users to register custom ERC20 tokens from the SHKeeper admin panel (or via a configuration file / environment variable), by specifying the contract address. Since all ERC20-compliant tokens expose the same standard interface (transfer, balanceOf, decimals, symbol, etc.), the existing daemon logic used for USDT/USDC should be largely reusable. The core idea is to decouple the token definition from the codebase and make it a runtime configuration.
Problem
SHKeeper currently supports a fixed set of ERC20 tokens (USDT, USDC) on the EVM-compatible chains it already integrates (Ethereum, BNB Chain, Polygon, Avalanche, Tron). There is no way for a user to add an arbitrary ERC20 token by simply providing its contract address.
This means that merchants who need to accept payments in other widely-used ERC20 tokens — such as DAI, WBTC, LINK, UNI, or any project-specific token — cannot do so without modifications to the codebase and a new release.
Proposed Solution
Allow users to register custom ERC20 tokens from the SHKeeper admin panel (or via a configuration file / environment variable), by specifying the contract address. Since all ERC20-compliant tokens expose the same standard interface (
transfer,balanceOf,decimals,symbol, etc.), the existing daemon logic used for USDT/USDC should be largely reusable. The core idea is to decouple the token definition from the codebase and make it a runtime configuration.