抵押现有的 ERC20 代币

Question

How do I make a existing running erc20 to prevent some holders from transacting?

I am trying to do a staking feature. Can I write a new contract to control the existing erc20 contract?

Answer 1

Logic that would affect a token holder's ability to transfer (or have a party transferFrom on the holders behalf) must be written into the contract if you want token transfers to be halted within the contract itself. Therefore, if you already have a contract deployed you would have to deploy a new ERC20 contract that has the logic - if you want the staking mechanism to be within the same contract. Then you would have to transfer balances from the previous version of the contract to the newly deployed contract. While possible, it would incur a gas expense to replicate the contract state. You could have your token holders pay this gas cost by having some sort of mint or recover function that would read the old contract balance for an address, create the balance on the new contract, and then mark the balance as transferred.

Alternatively, to your second question, you could facilitate the staking with an additional contract that users would set an allowance to within the ERC20 contract. Then, users could interact with something like a stake function on this new staking contract. The staking contract would use the transferFrom ERC20 function to transfer tokens from the owner to the staking contract's address after incrementing the user's staked token amount within the staking contract. This would record the holder's staking "credit" and tie the tokens up by transferring their ownership to the staking contract. Users could then unstake which would decrement the user's staked token amount and transfer the tokens back from the staking contract's address to the token holder's address. This type of approach has more moving pieces but could be a more flexible step while developing the mechanism as you can deploy new versions of the staking contract without having to redeploy the ERC20 contract or transfer balances. Users would be able to transfer like normal throughout multiple versions of the staking contract and extracting tokens from previous versions of the staking contracts would be gas-efficient.