Root Contracts
Last updated
Was this helpful?
Last updated
Was this helpful?
This page lists system level smart contracts and explains their role on Galactica.
The overview of addresses in the testnet can be found in .
The ZkCertificate registry contract holds the information about issued ZkCertificates. Each ZkCertificate is added as a hash to a Merkle tree and is revoked by setting this hash back to the default empty value.
The smart contract stores several merkle roots against which the membership proofs are verified. When a ZkCertificate is issued then the new merkle root is added to the set of valid roots. When a ZkCertificate is revoked then this set is emptied and only the newest one is deemed valid.
In order to avoid concurrency issue guardians need to register the ZkCertificate hash corresponding to their operation using the function registerToQueue(bytes32 zkCertificateHash). The operations in the queue are processed in the order they were registered. This function also assigns to the operation an expiration time until which the guardians need to perform the operation (and no other operation can be executed to avoid concurrency), otherwise it can be skipped. The expiration time is calculated as follows: if there is no other operation pending, then it is current block time plus 5 minutes, otherwise it is the expiration time of the last pending operation plus 5 minutes. Note that when an operation gets in turn (i.e. no other pending operation) in can also be executed immediately regardless of the expiration of the previous operation.
The verification SBT contract stores successfully completed ZkCertificate verifications. A mapping indexed by the hash of user address and DApp, contains information about the SBT, such as the expiration date and encrypted notes for the Galactica Investigation Module. Each verification SBT also has a tokenID and information can also be found using this tokenID.
The reputation root contract is smart contract interface to Galactica's reputation module. Users and DApps can define Reputation functions and configure Contingent Transactions.
First version still in development.
The ZkCertificate Guardian Whitelist contract manages which ZkCertificate Guardians are authorized to issue ZkCertificates.
It is meant as simple first solution to gather feedback. In the long term it will be replaced by a decentralized system based on reputation.
This smart contract contains the on-chain verification of a ZKP proving that the holder has a valid zkKYC and that the age is >=18. It demonstrates what verification steps are required to check that a ZKP is consistent with the on-chain state. It integrates the Example ZKP verifier contract.
The ZKP verifier contract contains the logic to verify if ZKPs are valid in themselves given the zero-knowledge circuit it is based on. This contract is auto generated from the circom2 circuit.
A simple contract stating an institution's public encryption keys.
The example DApp contract shows how to integrate zkKYC. The example mints a Verification SBT for user successfully proving that they are real and unique humans. The uniqueness of the user is based on the DApp specific HumanID.
The example DApp contract shows how to integrate zkKYC. The example use case airdrops tokens to users proving that they are real and unique humans. The uniqueness of the user is based on the DApp specific HumanID. So every user can receive the airdrop of a token only once.
Wrapping GNET as ERC20 token equivalent to WETH on Ethereum.
This is a library smart contract that provides the poseidon hash function to the zkKYC registry contract.
This smart contract contains the on-chain verification of a ZKP proving that the holder has a valid zkKYC. It demonstrates what verification steps are required to check that a ZKP is consistent with the on-chain state. It integrates the Example ZKP verifier contract generated from the associated ZK circuit.
This smart contract can be used for testing the ZKP submission. It checks that the ZKP and the zkKYC used for it are valid. After successful validation, a verification SBT is issued in the Verification SBT contract.
This contract issues zkKYCs on devnet for testing. It has the same interface as the #zkkyc-registry-contract and can be used by everyone. The sender of the transaction does not need to be on the #kyc-guardian-whitelist-contract.
The HumanIDSaltRegistry limits each user to a single salt for a unique HumanID. You can find details in DApp specific HumanID.