Some existing implementations and standards have functions that allow to freeze an account address, meaning any balance that currently exists or will be sent to the address. The idea was to make it clear that we really mean freezing some quantity of the token, let’s say 100 tokens and we’re not freezing the account address.
The same logic applies to destroyTokens. Here I would argue additionally that terminate may be misunderstood to terminate the smart contract as a whole.
To comply with the eWpG we wanted to have a single data field that represents the linkage between the on-ledger smart contract and the issuance conditions. As we didn’t specify the content or structure of the metaDataJSON field, we thought this to be necessary.
Links to IPFS could be added to the metaDataJSON, that would definitely decrease the risk that the documents becomes unavailable independent on the registrar.
I’m open to ideas on how to make the name paperContractHash more specific and better to understand. Do you have any ideas? As stated above, maybe using the terms {checksum, file, issuance document} is a way to go.
ERC-1155 may help here in implementing the different types of balances a holder may have. @MarkusKluge Anything to add here?
Sadly, with the limited time available I/we were not able to pursue this proposal as we would have wished for. As a result the EIP is not yet merged into the repo and thus not visible on https://eips.ethereum.org/.
That’s true; CIDs let you do fancy things like verify only a particular chunk of a file instead of the whole thing. What I didn’t realize is that you cannot easily verify that a particular file matches a CID without fetching stuff from IPFS, so please disregard my suggestion here.
There might be different types or (legal) statuses for securities. As this standard addresses typical TradFi Instruments as bonds, fonds, or shares we (and the law) already have identified several cases where some of the tokens of a token holder might have transfer restrictions because they are used as collateral. Still, corporate actions like dividend payments for these tokens are the same as for those without transfer restrictions. Other scenarios might be, that shares of a startup might have different rights than others like for example liquidity priority. In upcoming more sophisticated scenarios there hopefully might be more types and legal statuses for securities than the traditional financial industry can imagine right now.
A registrar of course can decide to handle these edge cases off-chain. But we think that we should be able to apply on-chain logic to those cases.
We introduced the compatibility with the ERC-1155 standard because we wanted to be able to reflect different legal statuses or types of tokens on-chain, to enable other smart contracts to interact appropriately with these statuses. But we also decided that these scenarios have to be reflected in sub-standards. A first EIP for the eWpG based on ERC-1155 and ERC-7551 is introduced with ERC-7570. Others might follow.
Do I understand correctly, that you would be encoding different types of positions in the token using the tokenid from ERC-1155 (e.g. collective or individual entry according to eWpG, but also for example for earmarking (Sperrvermerk)?
