openzeppelin-contracts VS openzeppelin-contracts-upgradeable

Lets look the events of Open Zeppelin’s ERC20 token contract:

ERC-777 is difficult to implement properly, due to its susceptibility to different forms of attack(opens in a new tab). It is recommended to use ERC-20 instead. This page remains as a historical archive.

This depends if you're writing a contract from scratch or using existing code. If you're making something new, then yes (recommend not to use THE most recent available, always better to go with tried and tested). For existing projects, never try to override the solidity version. This may be a pain with "@" imports - ideally everyone should specify the library version (e.g. https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.5.1/contracts/token/ERC20/ERC20.sol).

v4.8.2 of OpenZeppelin contracts and contracts-upgradeable bug fix for ERC721Consecutive that could cause a balance overflow when _mintConsecutive was used for batches of size 1 breaking changes to ERC721: the internal function _beforeTokenTransfer will no longer update balances when batchSize is greater than 1

Yeah. That restriction is coming from a utility. There are options to modify the owner through transfer ownership on the `OwnableUpgradable` contract. You can also use the `reinitializer' modifier to create your own re-init logic.

Most smart contracts developers have used Openzeppelin/contracts. Those developers dabbling in Upgradeable smart contracts use its sister project Openzeppelin/contracts-upgradeable. The two are the same albeit the constructor in the contract is replaced by the initializer.

Here’s a few references: - https://openzeppelin.com/contracts/ - https://github.com/OpenZeppelin/openzeppelin-contracts-upgradeable (highly recommended)

https://github.com/OpenZeppelin/openzeppelin-contracts-upgra...

For KYC you'll need to implement your own ERC20 compatible token with some checks in the transfer functions. The CMTA is the Swiss contract reference and proposes one: