This issue consists of a fairly large refactor of the settlement reistry contract, splitting it into two pieces:
- The
SemaphoreAdapter contract: tracks semaphore groups, membership, and verifies membership proofs
- The
SettlementRegistry contract: tracks prices and settlements, calls the semaphore adapter
The settlement registry contract should allow for a configurable pre-registration hook, rather than the hardcoded USDC condition. This enables bespoke conditions for gaining membership to the semaphore group, enabling conditions like private data based on identity, asset ownership, DAO membership, and so on.
The pre-registration hook is a one-time event per semaphore group registration. Given that the hook outputs a valid result, the identity becomes a member of the semaphore group. Post-membership, users only need to prove their inclusion, which can be done on-chain using the settle function. However, in order to include this hook, we must refactor the contract. It is already at the very limit of size (24.5kb) and fairly optimized. Instead, we need to split the contracts in two.
This issue consists of a fairly large refactor of the settlement reistry contract, splitting it into two pieces:
SemaphoreAdaptercontract: tracks semaphore groups, membership, and verifies membership proofsSettlementRegistrycontract: tracks prices and settlements, calls the semaphore adapterThe settlement registry contract should allow for a configurable pre-registration hook, rather than the hardcoded USDC condition. This enables bespoke conditions for gaining membership to the semaphore group, enabling conditions like private data based on identity, asset ownership, DAO membership, and so on.
The pre-registration hook is a one-time event per semaphore group registration. Given that the hook outputs a valid result, the identity becomes a member of the semaphore group. Post-membership, users only need to prove their inclusion, which can be done on-chain using the settle function. However, in order to include this hook, we must refactor the contract. It is already at the very limit of size (24.5kb) and fairly optimized. Instead, we need to split the contracts in two.