Current AllocationRegistry is the output of nucypher-deploy allocations and is a JSON file containing a dictionary of beneficiary addresses and "contract data", which is just a tuple of a contract address (i.e. the UserEscrow address for that beneficary) and the corresponding contract ABI.

Some inefficiencies of such design for the allocation registry:

• The contract ABI is the same for all UserEscrow contracts, so the registry is very redundant.
• It presumes that the same file that is the output of nucypher-deploy allocations will be used by allocation users when nucypher stake, which is not very convenient.
• The file contains the beneficiary address and UserEscrow address of all allocation users, which is only marginally useful for the deployer, but not for allocation users.

The work in #1227 that introduced UserEscrow staking with the CLI continues to use said design for AllocationRegistry as a compromise to not change too much in a single PR, but this must change in a subsequent PR, part of the biznaga EPIC.

Proposal

1. Instead/In addition of current allocation_registry.json file, the nucypher-deploy command will output:

   • A file with just the ABI of the UserEscrow contract, which recall it's the same for all allocation users. Let's call this file allocation_contract_ABI.json.
   • A small file for each allocation user containing the beneficiary address and the corresponding UserEscrow contract address. Let's call this file allocation_user_0xfoobar.json, where 0xfoobar is the beneficiary.

2. allocation-contract-ABI.json is uploaded to the "master registry repo" (currently in GH), together with the contract registry (contract_registry.json).

3. allocation_user_0xfoobar.json is sent to the allocation user 0xfoobar.

4. When allocation users stake using nucypher stake, they'll have to provide either:

   • Both the --beneficiary-address 0xfoobar and --contract-address 0xabc123
   • A path to an allocation_user_0xfoobar.json file, which recall contains just a tuple with the beneficiary and UserEscrow contract addresses.

Any comment or alternative proposal is welcome!