7. Redeem Incognito Credits
Spent Claims provide access for users to redeem earned Incognito Credits (IC). Please note that only withdrawn claims can earn IC - claims that have not been withdrawn cannot receive IC. This is because the zero-knowledge proof clocks in how many ICs are owed to the user only after the principal is withdrawn (depending on how long the asset stayed in the Sacred pool). The IC a user receives will vary depending on the Sacred pool, and is determined by the Sacred DAO.
For Example, if the instance size is 10 ETH: IC per block 20
From an observer’s point of view of the Incognito Account, they will only be able to see that someone claimed some IC batch of unknown size for some claim for a certain Sacred pool. To further obscure this transaction, Sacred users can use a relayer to redeem IC via a relayer and IC will be accepted as compensation to cover the relaying costs.
Since Incognito Credits are by nature, private, they cannot be stored in any wallet and need to be stored in the user’s Incognito Account. This account is created by the user generating a secret key that stores the user’s IC balance. This key is encrypted by the user’s Polygon Public key (using Metamask’s eth_getEncryptionPublicKey) and stored on-chain. If the user loses their Incognito Account key, they can recover it by using their Polygon key that was used to encrypt it.
Once the user transfers the IC into the Incognito Account, it is ready to be swapped into SACRED. The user will need to use Sacred’s Automated Market Maker (SAMM) to exchange IC to SACRED.
Code Summary - Claiming Rewards
User Inputs:
3. Note
4. Recipient Address
5. Relayer settings (relayer URL, fee amount) or current wallet
Process:
5. Browser (front-end only) decodes the Note (more info on Note structure in proof generation section).
6. Check if Note is valid, check if deposit still exists (check Merkle Tree)
7. Arguments set to the contract:
a. proof (zksnark output)
b. root (merkle tree)
c. Nullifier recipient address
d. relayer (address)
e. fee
f. refund (non native currency only)
8. Contract verifies proof, marks that nullifier used and sends funds to:
a. User (denomination - fee)
b. Relayer (fee) - if used
9. Front-end catches transaction receipt and displays all relevant info
Outputs:
Transaction receipt
Last updated
