Audit suggestion: Relayer Registry

Hi everyone ! :relaxed:

There is an up-and-coming relayer registry proposal for the tornado protocol, coded by @CommunityDev13337. This is a summary of what this proposal (read: upgrade) would enable for the protocol:

  • The proposal enables mechanics which can, if passed via the proposal, in combination with existing software, change how relayers register with the system.
  • If the community decides to pass the proposal, relayers will have to register with a registry and deposit some TORN as a mechanism of investment in the protocol to discourage misbehaviour and spamming, or not be listed on the frontend.
  • If relayers misbehave governance may elect to slash their funds.
  • Deposited TORN will be burned on withdrawals and distributed to people that engage with Governance.
  • Relayers will not have to stake necessarily, but in this case they will not be listed on the frontend.

The contracts for this upgrade still need to be deployed on mainnet, but before that the source code logic should be audited for safety.

This post proposes a Snapshot vote, which will be set up, as always by our famous @Rezan to determine if the community wants the source code for the afordmentioned set of contracts to be audited, which would in turn be paid from the treasury. The approximate cost of the audit would be 45k$.

The set of contract source code can be found here, the audit would be held in approximately one week. There is still a design change that would be made to the repository given the recent input of several reputable solidity engineers, but the current architecture would be very (very) close to what it is currently.

Thanks for taking the time to read this through and keep it :tornado:.

And thanks to @CommunityDev13337 for answering any technical questions or opinions that will be posted here.

3 Likes

Thanks for the post, @bt11ba ! Open for questions here, as stated.

2 Likes

Could you explain what this bullet means in a bit more detail?

1 Like

Upon TORN deposit, this deposit is transferred to a staking contract which calculates rewards based on a modified version of the Synthetix staking contract logic (increments rewards when withdrawal happens). Accounts which have TORN locked in Governance are automatically accredited TORN rewards (updated on each lock / unlock), and are claimable through a dedicated function of the Staking contract.

1 Like

Very cool to see some progress on relayers.

I had a glance at the repo and have some questions for @CommunityDev13337

It is a bit challenging to review the code without also reviewing:

  • Changes to the tornado-relayer repo (I assume this will change?)
  • Changes to the frontend.
    – How does the frontend select a relayer, how does it interact with these new contracts? Is there randomness selecting a relayer?

Overall, this is bigger than I expected. Interested to learn who is auditing it. They will need to understand tornado well.

  • Minimum stake is only checked on Registration. What if min is increased after registration? Do we expect relayers to increase their stake, or are they grandfathered in?
  • A registered relayer can run out of stake (as the stake is slowly burned)
    • What is the specific order calling the burn function?
    • Does the relayer relay the transaction, and then the proxy calls burn? Who pays the gas?
    • If a burn is happening every time a note is redeemed, it is going to increase gas costs. Has anyone measured the gas cost of RelayerRegistry ⇒ burn? Seems quite expensive.
    • Is the note redemption and burn all atomic? Does the proxy only redeem a note if the burn succeeds? Can a relayer with 0 stake left still be selected by the frontend?
  • TornadoStakingRewards ⇒ withdrawTorn allows governance to take all staked torn from all relayers. This should be made pretty clear when a relayer registers.
  • From what I can see, becoming a relayer is a one way street. You can register, but if you unregister, you don’t get your TORN back. It is stuck forever. Correct?

Finally - again maybe a frontend question:

  • Does registering on one chain mean you will be relayer on all chains?
    • How does the cross-chain situation work?
    • If the goal is for relayers to be cross-chain, should you add a way to register non-ETH addresses now so you don’t need to do an upgrade?
    • If the plan is for relayers to register on each chain, what are they going to stake?
2 Likes

Just checked again right before going to sleep, will now go in on contract questions and follow up on others later if you are fine with it.

Understandable, it is still under code review process too. The audit has been scheduled for the end of this week, thus laying this out while everything is being in parallel prepared for the audit. Auditors have tight schedules :sweat_smile:

If min is increased after registration he continues using his balance as normal until he does not have a sufficient amount left. They are not expected to increase their stake.

  1. The Governance contract calls burn on the Registry when withdraw is used, this calls addBurnRewards of the Staking Contract (msg.sender == Registry).
  2. The gas is paid by the relayer.
  3. Local testnet tests are 430k gas, currently I saw averages of 380-400k on mainnet.
  4. It’s all part of the same function, yes, only if the burn succeeds, unless relayer is not registered. Not working on the frontend so cannot tell you right now.

Yes, but in this case relayer balances do not change.

Correct.

1 Like

thanks for putting up the work! I see the vote at Snapshot got 2.46k TORN of ACCEPT. does it mean a pass or no?

Guys, I am new here, so sorry for a newby question regarding voting on snapshot. Do I understand correctly, that it is not voting on eth main net, where it would cost gas. So the voting on snapshot costs no gas and is free of charge. Right?
And the second question. When the voting is regarded as accepted? Yes>No or Yes>NO and SomeMinNumOfVoters or something else?
Thank you in advance!

yeah that’s correct.

When the voting is regarded as accepted? Yes>No or Yes>NO and SomeMinNumOfVoters or something else?

Not sure either.