IERC1400TokensSender in ERC1820 Registry about universaltoken

[jasonclinx]

@victorwiebe got you! Yes 'setHookContract()' is the key part to make it work.

[onigiri-x]

@jasonclinx I can help I guess, I also found this a bit weird. Have you used the hook method?

For example , working from the unit tests the consensys team wrote - in my (forked) unit test I do

await this.token.setHookContract(this.validatorContract.address, ERC1400_TOKENS_VALIDATOR, { from: owner });`
          let hookImplementer = await this.registry.getInterfaceImplementer(this.token.address, soliditySha3(ERC1400_TOKENS_VALIDATOR));
          assert.equal(hookImplementer, this.validatorContract.address);

That has been sufficient for my token extensions, along with
ERC1820Implementer._setInterface(ERC1400_TOKENS_VALIDATOR);

in the constructor

And then when I want to query the ERC1820 registry for the ERC1400 Tokens validator associated with the security token, I use this typescript

  const erc1400ValidatorHash = await this.erc1820RegistryContract.interfaceHash(
                this.ERC1400_TOKENS_VALIDATOR,
            );

            const erc1400ValidatorAddress = await this.erc1820RegistryContract.getInterfaceImplementer(
                securityTokenAddress,
                erc1400ValidatorHash,
            );

Hope that helps.

[onigiri-x]

Thats my understanding. The unit test simulates real world behavior- and in the unit test you can see setHookContract is used for this. I would recommend you looking at the unit tests if you are confused how to work it.

I am trying to keep info on the blockchain, that is why I go further and use this methods to query the ERC1820 registry instead of keeping track myself the contract address. I had to figure this one out.

 const erc1400ValidatorHash = await this.erc1820RegistryContract.interfaceHash(
                this.ERC1400_TOKENS_VALIDATOR,
            );

            const erc1400ValidatorAddress = await this.erc1820RegistryContract.getInterfaceImplementer(
                securityTokenAddress,
                erc1400ValidatorHash,
            );

In the repo, in ERC1400Raw there is the following code:

  /**
   * [NOT MANDATORY FOR ERC1400Raw STANDARD]
   * @dev Set validator contract address.
   * The validator contract needs to verify "ERC1400TokensValidator" interface.
   * Once setup, the validator will be called everytime a transfer is executed.
   * @param validatorAddress Address of the validator contract.
   * @param interfaceLabel Interface label of hook contract.
   */
  function _setHookContract(address validatorAddress, string memory interfaceLabel) internal {
    ERC1820Client.setInterfaceImplementation(interfaceLabel, validatorAddress);
  }

Hope this helps. Obviously @gauthierpetetin will be able to better answer this, but I hope my comments can keep you on your path. The more us open source guys contribute the better the software and knowledge base will be for everyone over time

[onigiri-x]

Just to clarify and make sure we are on the same page, you dont need to run the unit tests to get the project working. That is what migrations are for if you want to deploy things automatically set up. But the unit tests show us what we can do with the token+javascript. You can call sethookcontract on your choice of provider, and environment whether it be a node.js project with ethersjs/web3, or remix, etc. You just need to call the function

The tl;dr here is method:

setHookContract(address validatorAddress, string interfaceLabel)

[jasonclinx]

@victorwiebe thanks Victor. Do you mean the registration actually takes place in unit test? Once the unit test is run and passed, the validator has been registered in ERC1820 and no need to call "setHookContract" anymore when deploying the contracts.

[jasonclinx]

@victorwiebe thanks that helps.

"The unit test simulates real world behavior" this makes sense. A little bit strange though because traditionally we won't expect the up and running of a system is subject to running unit tests beforehand. Maybe @gauthierpetetin could elaborate more about the design.

[gauthierpetetin]

Yes thank you @victorwiebe for the clear explanation!

Indeed the only contract to deploy is the token contract, e.g. ERC1400ERC20.sol (or ERC1400.sol if you don’t care about ERC20 backwards retro-compatibility).
Once your token contract is deployed, you can eventually add an extension but this is optional.
What we want to foster in target, is developers to use the token contract as it is, and add their custom extensions to adapt it to their use case.

Example: deploy a transfer validator extension (ERC1400TokensValidator.sol)
Objective: the transfer validator extension allows to control transfers in a custom way (with a whitelist, a blacklist, etc.)
How to deploy the validator: reproduce what is done in the migration file, e.g.:

1. Deploy the transfer validator extension (ERC1400TokensValidator.sol)
2. Once deployed, indicate the address of the transfer validator extension to your token contract by calling setHookContract(validatorExtensionAddress, “ERC1400TokensValidator”)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.