How is it possible for Centre and the like to blacklist Ethereum addresses when they themselves are not miners/validators?

External question — Ethereum Stack Exchange Author: John Smith Original post: https://ethereum.stackexchange.com/questions/93352 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. There is no shortage of the news on stablecoin censorship, in particular blacklisting of Ethereum addresses: Tether has been blacklisting Ethereum addresses that hold USDT for a couple of years now—this year alone, Tether has blacklisted 24 addresses that hold a total of $5.51 million USDT in summation. [...] Tether has blacklisted a total of 39 out of the 1.47 million Tether addresses that exist, which represents a total of 0.00002% of all tether addresses. When a tether address is blacklisted, it can’t send, receive, or redeem USDT. Assuming that the said stablecoin issuers are not miners/validators, how are they able to do censor sending and receiving? Does such censorship involve also NFTs , Eth, and other erc-20 tokens? Could similar censorship be done by MakerDao?

External answer — Ethereum Stack Exchange Author: Richard Horrocks Original post: https://ethereum.stackexchange.com/a/93353 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. They own the contracts. For example, one of the Tether contracts is named BlackList . This contains a mapping: mapping (address => bool) public isBlackListed; ...which can be updated by the owners using addBlackList() . When an address is added to the blacklist, that address can no longer use its Tether balance.

External answer — Ethereum Stack Exchange Author: Mehdi Rezaei Original post: https://ethereum.stackexchange.com/a/172430 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. Ethereum’s consensus only determines which transactions execute and what the global state becomes. It does not require every token to be freely transferable. USDC and similar tokens implement the restriction in the ERC-20 contract itself. A simplified version looks like: require(!isBlacklisted[from] && !isBlacklisted[to], "blacklisted"); _transfer(from, to, amount); The mapping and the guard are application logic. The real contracts may use names such as isBlacklisted , blacklister , or BLACKLISTER_ROLE , and may also restrict minting, burning, or allowances. Circle controls a privileged role (through an owner, admin, or role-management contract). An authorized account can submit a normal Ethereum transaction that calls the token contract to update its blacklist mapping. Miners/validators include that transaction just like any other; they do not grant Circle special access to Ethereum. After the mapping is changed, a later transfer or transferFrom from or to that address executes the token’s guard and reverts. ETH itself, the Ethereum consensus rules, and unrelated tokens are unaffected. The token balance may still be recorded in the contract, but the issuer’s code can prevent it from being moved or can provide separate freeze/burn behavior. So this is an issuer policy enforced by smart-contract code, not a rewriting of the blockchain. The contract source, role assignments, and emitted events can be inspected on-chain to verify who has that authority.