Smart contract templates for publishing BrightID verifications on-chain and using those verifications.
A template contract that can be used to publish BrightID verifications signed by trusted BrightID nodes on-chain. Apps can query the signed verifications from trusted BrightID nodes using:
GET /verifications/{context}/{address}?timestamp={seconds/milliseconds}&signed=eth&verification={verification_expresssion}
and call the verify function with the contextIds, timestamp and v, s and s fields of the sig provided in the response.
verify(address[] memory addrs, uint timestamp, uint8 v, bytes32 r, bytes32 s)
-
Apps should use a
verifierERC20 token to be distributed between the addresses used by their trusted nodes to sign verifcations. The Node One uses0xb1d71F62bEe34E9Fc349234C201090c33BCdF6DBto sign verifications so apps should send their verifier token to this address to be able to use its signatures. Theverifertoken address should be set on the contract by passing to the constructor orsetVerifierTokenfunction. -
Apps can query customized verifications like
BrightIDorSeedConnected and Yekta.rank > 2from BrightID nodes. Thesha256of the verification expression is included in the response asverificationHashand should be set on the contract by passing to the constructor orsetVerificationHashfunction.
A template contract that can be used to publish BrightID verifications on-chain in a decentralized way.
Using this contract we can define some supervisor BrightID nodes that monitor verifications proposed by proposer nodes and prevent publishing wrong verifications on the contract by calling stop function. This superviosry service can automatically be done using The BrightID Supervisor service.
An interface to above verification publishing contracts that different dapps can use to check if an address isVerified
and access history of addresses used by a single user.
A template contract that show how dapps can use isVerified and history to distribute a predefined amount of a token between verified BrightID users.
An interface that should be implemented by dapps that want to sponsor their users on-chain. Such apps should emit the Sponsor event in their contracts when
the user had enough interaction to be sponsored in their dapp.
An example--used by Rare Coin Claims--to distribute tokens at regular intervals to unique humans. Claimants are allowed to change their address only once per registration period.