Using a Relayer to withdraw the principal, IC and yield
To further achieve a state of privacy, Sacred uses Relayers.
The problem with blockchain transactions on Ethereum, Polygon and similar chains, is that the user will need to pay for gas. To pay for gas, a wallet needs MATIC. To get MATIC to pay for gas, a user might get it from an exchange or a friend or from themselves, maybe from a wallet that is already connected to their identity. Now a malicious actor can find out where their MATIC came from and link it with the user’s identity. Relayers help solve this problem.
Asset withdrawals and Yield earned can be redeemed anonymously to a “clean” wallet, aka a wallet with no ETH or MATIC, through relayers. A relayer is a privacy-preserving payment mechanism that protects anonymity by sending and paying for the transaction on their behalf. The relayer is refunded for the gas fees by deducting the gas fees from their withdrawal. A relayer cannot act maliciously as the ZK-SNARK proof is generated from their local device and verified on-chain. This Zero Knowledge Proof also contains the receiving address as part of the proof calculation so that they can be sure that nobody can tamper with it. Furthermore, the yield redemption mechanism is separate from the initial principle — this separation further ensures the security and anonymization of transactions.
The relayer is basically a web server with the following functionalities: Status Check (of itself) Queue Jobs Execute Jobs Sacred Withdraw Mining Reward (AP Claim) Mining Withdraw (AP → SACRED swap)
The withdrawal process with the relayer is summarized below.
Code Summary - Relayer
User inputs: (same as withdraw on Front-End UI)
Note
Recipient Address
Relayer settings (relayer URL, fee amount)
Parameters passed to the Relayer (browser processed the user input):
Contract Instance (Address)
Proof
Root
Nullifier Hash
Recipient (address)
Relayer (address)
Fee
Refund
The relayer receives the Parameters and executes the withdraw contract function (see above). The relayer never has possession of the user’s deposit/withdrawn funds. The contract handles all payments; the relayer is only executing the transfer function by providing the user’s proof.
Note: Because the proof is generated using parameter values like the recipient address, a relayer cannot tamper with the proof or arguments to have a successful withdrawal. A malicious relayer will have the transaction rejected and the User’s funds will stay inside the contract and count as being not withdrawn (also at the expense of the relayer who paid for gas until the contract reverted).
Last updated
