#16: Relayer registry penalisation and configuration

Proposal
#1

Since the deployment of the relayer registry in proposal #10, we have seen an additional utility for the protocol’s native governance token, allowing a hedge for stakeholders to accrue a percentage of protocol cashflows. This is executed by requiring relayers whom wish to be listed on the frontend to stake a balance into the registry, which a percentage (currently configured to 0.3%) is deducted whenever a withdrawal is processed to be distributed to active stakeholders in the governance contract. This action is only enforced when relayers process a withdrawal through the router, and not to the instance contracts directly.

Although since the time of such feature deployment, the market evaluation of the governance token has decreased significiantly - falling approximately 90% in value - maintaining justifiable thresholds for relayer operation is important for equitable participation. Otherwise the cost to deploy multiple relayers to game the randomisation logic for selection on the frontend is insignificant to the profit obtained from doing so.

Additionally as of late, we have see a number of relayers attempt to game the system by modifying the relayer client source code to evade the router and process withdrawals to instance contracts directly - while still being listed on the frontend - and not having to face deductions from their staked balance. While this does not effect the intended logic of the core protocol, it goes against the canon and requirements of being a relayer listed on the registry.

As requested by multiple community actors, this proposition enacts on two operations:

  • increases the registry’s listing minimum staking amount to 2000 TORN from 300 TORN
  • penalises the following relayers whom have been witnessed to evade the router, by reseting their staked balances to zero:
    • moon-relayer.eth
      • 0x30F96AEF199B399B722F8819c9b0723016CEAe6C
    • tornado-relayer.eth
      • 0xEFa22d23de9f293B11e0c4aC865d7b440647587a
    • secure-tornado.eth
      • 0x996ad81FD83eD7A87FD3D03694115dff19db0B3b
    • tornado-secure.eth
      • 0x7853E027F37830790685622cdd8685fF0c8255A2
    • tornado-crypto-bot-exchange.eth
      • 0x36DD7b862746fdD3eDd3577c8411f1B76FDC2Af5
    • torn69.eth
      • 0x18F516dD6D5F46b2875Fd822B994081274be2a8b
    • available-reliable-relayer.eth
      • 0x853281B7676DFB66B87e2f26c9cB9D10Ce883F37
    • tornrelayers.eth
      • 0xaaaaD0b504B4CD22348C4Db1071736646Aa314C6
    • 0xtornadocash.eth
      • 0x0000208a6cC0299dA631C08fE8c2EDe435Ea83B8
    • lowfee-relayer.eth
      • 0xf0D9b969925116074eF43e7887Bcf035Ff1e7B19
    • torn-relayers.eth
      • 0x12D92FeD171F16B3a05ACB1542B40648E7CEd384

Additionally to these changes the frontend logic to select relayers has been modified so each relayer must have a minimum balance of at least 500 TORN instead of the previous configuration of 40 TORN, making evading the router again costly if penalisation was to occur.

While this proposal does not address the long terms problem of modifying relayer software through build attestation, it sets percendents that misbehaviour is not tolerated.

1 Like
#2

Hello, our reply follows.

The important

It is important to note that the current proposal contract published does not do anything with the nullified funds. Since burn rewards are only added when calling the function StakingContract.addBurnRewards, and since no transfer out of staking contract via StakingContract.withdraw is present, the funds will be left, BUT NOT STUCK, in the staking contract.

It would possibly be preferable to immediately move them if anything to governance. If uninterested in the discussion, please drop to the last category.

Our opinion

We would like to touch on some points such that the wider community can see a wider elaboration. But one important question first:

  1. Have these relayers also been accused of not fulfilling transactions and behaving maliciously or not?

If so, they should be slashed immediately, the rest of the text can be read through but ignored in this case.

The following is written because we cannot be certain whether the author intended to nullify and addBurnRewards or only nullify.

We would like to state, first of all, that we definitely encourage quick and simple actions that drive the protocol forward, but we want to still discuss these issues properly.

We definitely agree that frontends should have tough, and we would demand even tougher, requirements to be listed as a relayer, and if some relayers go against this ethos, it seems fitting to de-list them. But, we would like to question whether slashing relayers for modifying relayer code to process transactions directly through instances is an appropriate punishment, because this involves manipulating the staked tokens.

We ultimately do understand that the criteria for slashing a relayer, may be defined by governance (whatever the definition), but we do ask ourselves how this influences the present incentive structure.

Most importantly, discarding the intentions of the relayers, they cannot be blamed for being automatically listed on the frontend while at the same time processing transactions directly through instances. Since this issue is now known, better measures can be developed in an attempt to reward present relayers more.

We could consider, that this is simply intended contract functionality that relayers can opt to use instances without having to stake anything, but that they then must not receive the benefits of so to say being included in the community.

The problem then becomes: what should be done when relayerStake != 0 but the relayer processes transactions directly? The logical conclusion would be that the relayer should be able to signal that he is intending to pause operating under governance and is requesting to be removed from the frontend, and if the relayer does not do this only then should a relayer be slashed.

Since this is impossible to do retroactively, our recommendations follow.

Our recommendation

Since we cannot be certain whether the author intended to nullify and burn or only nullify, we would like to recommend the following in the case of the former:

Instead of also burning the the relayer funds, the nullified funds could be moved to the governance contract such that they are not consumed. This is trivial to implement, the to-be nullified amounts could be first read out by doing RelayerRegistry.relayers(address) for each relayer, then those funds could be nullified, and then the function StakingContract.withdraw(sum) could be called.

Additionally, (we are not sure what the likelyhood of this happening is), hex encoded messages could be sent out from either from governance as internal transactions if this is possible, or from EOA’s not tied to governance, to the relayers requesting they send a signed statement to governance on what their above mentioned intention is. Otherwise, if the relayers do not within a certain time-span or in consideration of other commonly understood signals make a statement, add those funds as burn rewards.

We can assist with this.

Lastly, in any case, considering the current environment, we still prioritize quick actions and not over-complicating, but moving the funds to gov is still a viable option.

Thank you.

1 Like
#3

Signature of the copied text from above for this public key which we will use in future.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEFAR9+kY8p0eJgLUw4MRQnWUbtakFAvSG/8AACgkQ4MRQnWUb
takQxQ/6Ash78tladrZZ4EDNexuSvux4dWJnk83HlXIlVEK9n0i9CNNQ4uPWPCMt
rnCf+C0HO4tsxMrRh9fV4lvJx5my/R2dLCNFesz+zo7KWqV+u1+KsPrcJrH+MnL8
ZUKOeFMW+7Vo54IFG5gliRFzjcfpcw1XRDcgYywsDEWgQ6Ng62AOujEwcGGst90o
4StP0wtswL+ZRgwVvrUR5EvMmCMGrcv6hrFJuD8/dxw7d3qnB+sc7MNV8lr3hOs4
H878QYuH3dAGbcc1bccrj/Nnvs4KnSDYiM0RuaUHHJtODFBK1S3AkzmTTGlGAbYH
M4nKfKc077iKO4ZvoOZHdBW3iLdi4WLe9dZPl4b7gHYZEqSO4no/8TUJBj+39BOL
3gIqVxDtsAiZC+raiculLr1SWFqnambBpbREUPL3Bvfx3WK63bE8ulYPEl7bLshd
eu7IH+qEcCswevR69mc7Bazn5/VrdIj2Il33ygVbof+ki1T+BOFPVFiiuOagW3rJ
lzBjT9v/yTkZPK2EUET7pxRvMbAtBl+nmObxLITLUHJ3DQauGTkcy3WLLNlHsUZ+
9Q5b1g3wgVLn0/5p1RW/wqzIzvKR262YwZd1X1uKBO3FroqVeGyImRXLnaBlXY4p
WhT1hdnypapauH3Imzfvhf8imPRrFp4t0lJ78v9nPM2gYr8ikzU=
=viCH
-----END PGP SIGNATURE-----

#4

Thank you for mentioning this, I missed that staked relayer balances are transferred directly into the staking rewards contract. I do not think penalisation rewards should be rewarded to governance stakeholders as it is counterintuitive. Additionally the logic to add burn rewards isn’t as simple as an uint value, the reward multiplier is updated through the fee manager contract and the potential implications would need to be thoroughly assesed before doing so.

Although I agree about withdrawing it back to the treasury to avoid unneccessary and complicated proxy accounting at a later date. Now the proposal first queries the balances of all violating relayers before the nullification and withdraws it to the treasury after the penalisation has been executed.

2 Likes
#5

These cheating relayers have basically recovered the stake cost and made a profit. Clearing their staked TORN to 0 is not wrong.
I also agree to move their staked TORN to treasury.

2 Likes
#6

I found that the address of the cheating relayer in the proposal is not complete, and I hope to complete the address of the cheating relayer, so I collected the transactions of five smart contracts and counted the address of the cheating relayer. The five smart contracts are:
(1) 0x00fce327a1c64b24a626c353e68222275d184c40 (a smart contract created by cheaters to avoid torn burning)
(2) 0x12d66f87a04a9e220743712ce6d9bb1b5616b8fc (tornado cash’s 0.1 eth contract pool, I have collected all the relayer addresses that bypass the router to initiate withdrawals since 2022-02-21)
(3) 0x47ce0c6ed5b0ce3d3a51fdb1c52dc66a7c3c2936 (tornado cash’s 1 eth contract pool, I have collected all the relayer addresses that bypass the router to initiate withdrawals since 2022-02-21)
(4) 0x910cbd523d972eb0a6f4cae4618ad62622b39dbf (tornado cash’s 10 eth contract pool, I have collected all the relayer addresses that bypass the router to initiate withdrawals since 2022-02-21)
(5) 0xa160cdab225685da1d56aa342ad8841c3b53f291 (tornado cash’s 100 eth contract pool, I have collected all the relayer addresses that bypass the router to initiate withdrawals since 2022-02-21)

smart_contract_addresst : 0x00fce327a1c64b24a626c353e68222275d184c40 (a smart contract created by cheaters to avoid torn burning)
time : since contract creation
cheating_relayer_address total_fee ( profitable eth amount )
0x853281b7676dfb66b87e2f26c9cb9d10ce883f37 65.6917031957394
0x36dd7b862746fdd3edd3577c8411f1b76fdc2af5 16.717259145164093
0x87bedf6ad81a2907633ab68d02c44f0415bc68c1 10.766639069307196
0x0000208a6cc0299da631c08fe8c2ede435ea83b8 23.98433300827913
0xaaaad0b504b4cd22348c4db1071736646aa314c6 31.297310728773336
0x18f516dd6d5f46b2875fd822b994081274be2a8b 5.508262580467298
0xefa22d23de9f293b11e0c4ac865d7b440647587a 3.39861781990085
0x7853e027f37830790685622cdd8685ff0c8255a2 2.0143787552429
0x30f96aef199b399b722f8819c9b0723016ceae6c 2.4188810071535998
0x996ad81fd83ed7a87fd3d03694115dff19db0b3b 3.7391261504782496
0xf0d9b969925116074ef43e7887bcf035ff1e7b19 0.47940018590609995

smart_contract_addresst : 0x12d66f87a04a9e220743712ce6d9bb1b5616b8fc ( tornado_cash_0.1_eth )
time : after february 21, 2022
block height : after 14248860
cheating_relayer_address total_fee ( profitable eth amount )
0x2209efc366594f813e1fcdd9401560a69f1575f4 0.6009731678969998
0x87bedf6ad81a2907633ab68d02c44f0415bc68c1 0.0439102423736
0x0000208a6cc0299da631c08fe8c2ede435ea83b8 0.0056970179495
0x853281b7676dfb66b87e2f26c9cb9d10ce883f37 0.016952391565499998
0x36dd7b862746fdd3edd3577c8411f1b76fdc2af5 0.01081
0x30f96aef199b399b722f8819c9b0723016ceae6c 0.8036200755181498
0xa0959536560776ef8627da14c6e8c91e2c743a0a 0 ( because he used his own relayer to transfer funds to his relayer receiving address )
0xefa22d23de9f293b11e0c4ac865d7b440647587a 0.25037675394470005
0x996ad81fd83ed7a87fd3d03694115dff19db0b3b 0.26639931801455
0x18f516dd6d5f46b2875fd822b994081274be2a8b 0.1484426056223
0x12d92fed171f16b3a05acb1542b40648e7ced384 0.02539394389085

smart_contract_addresst : 0x47ce0c6ed5b0ce3d3a51fdb1c52dc66a7c3c2936 ( tornado_cash_1_eth )
time : after february 21, 2022
block height : after 14248860
cheating_relayer_address total_fee ( profitable eth amount )
0x2209efc366594f813e1fcdd9401560a69f1575f4 1.1829117785525993
0x14812ae927e2ba5aa0c0f3c0ea016b3039574242 0.07131334552455
0x87bedf6ad81a2907633ab68d02c44f0415bc68c1 0.0453266494782
0x0000208a6cc0299da631c08fe8c2ede435ea83b8 0.02339548123445
0x853281b7676dfb66b87e2f26c9cb9d10ce883f37 0.0453263096026
0x36dd7b862746fdd3edd3577c8411f1b76fdc2af5 0.0077163414836
0x30f96aef199b399b722f8819c9b0723016ceae6c 1.3002595854966004
0xefa22d23de9f293b11e0c4ac865d7b440647587a 0.3443773382933
0x996ad81fd83ed7a87fd3d03694115dff19db0b3b 0.42057687159194995
0x18f516dd6d5f46b2875fd822b994081274be2a8b 0.20792786835670002
0x7853e027f37830790685622cdd8685ff0c8255a2 0.0134432832522
0x12d92fed171f16b3a05acb1542b40648e7ced384 0.07432896663265

smart_contract_addresst : 0x910cbd523d972eb0a6f4cae4618ad62622b39dbf ( tornado_cash_10_eth )
time : after february 21, 2022
block height : after 14248860
cheating_relayer_address total_fee ( profitable eth amount )
0x2209efc366594f813e1fcdd9401560a69f1575f4 1.3418386644462497
0x87bedf6ad81a2907633ab68d02c44f0415bc68c1 0.18836512319745
0x36dd7b862746fdd3edd3577c8411f1b76fdc2af5 0.1184701826522
0x0000208a6cc0299da631c08fe8c2ede435ea83b8 0.13256830564005
0x853281b7676dfb66b87e2f26c9cb9d10ce883f37 0.15021814342345002
0x30f96aef199b399b722f8819c9b0723016ceae6c 14.910471218333928
0xefa22d23de9f293b11e0c4ac865d7b440647587a 0.6243652229272499
0x996ad81fd83ed7a87fd3d03694115dff19db0b3b 1.1435207459945502
0x18f516dd6d5f46b2875fd822b994081274be2a8b 0.8841042716483002
0x7853e027f37830790685622cdd8685ff0c8255a2 0.07401298504125
0x12d92fed171f16b3a05acb1542b40648e7ced384 0.35541078062735

smart_contract_addresst : 0xa160cdab225685da1d56aa342ad8841c3b53f291 ( tornado_cash_100_eth )
time : after february 21, 2022
block height : after 14248860
cheating_relayer_address total_fee ( profitable eth amount )
0x87bedf6ad81a2907633ab68d02c44f0415bc68c1 5.02991439433905
0x14812ae927e2ba5aa0c0f3c0ea016b3039574242 4.765575052139799
0x36dd7b862746fdd3edd3577c8411f1b76fdc2af5 3.48393339067825
0x853281b7676dfb66b87e2f26c9cb9d10ce883f37 4.1131122837328995
0x0000208a6cc0299da631c08fe8c2ede435ea83b8 1.2632497199869
0x30f96aef199b399b722f8819c9b0723016ceae6c 15.921254166301798
0xefa22d23de9f293b11e0c4ac865d7b440647587a 5.0662164654960495
0x996ad81fd83ed7a87fd3d03694115dff19db0b3b 6.6976831296659
0x18f516dd6d5f46b2875fd822b994081274be2a8b 1.2613592484607001
0x7853e027f37830790685622cdd8685ff0c8255a2 1.4615213641099
0x12d92fed171f16b3a05acb1542b40648e7ced384 4.1493957022235985

The following is the sum of the above tables :
cheating_relayer_address total_fee ( profitable eth amount )
0x853281b7676dfb66b87e2f26c9cb9d10ce883f37 70.01731232406384
0x36dd7b862746fdd3edd3577c8411f1b76fdc2af5 20.338189059978145
0x87bedf6ad81a2907633ab68d02c44f0415bc68c1 16.07415547869549
0x0000208a6cc0299da631c08fe8c2ede435ea83b8 25.409243533090024
0xaaaad0b504b4cd22348c4db1071736646aa314c6 31.297310728773336
0x18f516dd6d5f46b2875fd822b994081274be2a8b 8.010096574555297
0xefa22d23de9f293b11e0c4ac865d7b440647587a 9.68395360056215
0x7853e027f37830790685622cdd8685ff0c8255a2 3.5633563876462504
0x30f96aef199b399b722f8819c9b0723016ceae6c 35.354486052804084
0x996ad81fd83ed7a87fd3d03694115dff19db0b3b 12.2673062157452
0xf0d9b969925116074ef43e7887bcf035ff1e7b19 0.47940018590609995
0x2209efc366594f813e1fcdd9401560a69f1575f4 3.1257236108958506
0xa0959536560776ef8627da14c6e8c91e2c743a0a 0 ( because he used his own relayer to transfer funds to his relayer receiving address )
0x12d92fed171f16b3a05acb1542b40648e7ced384 4.604529393374449
0x14812ae927e2ba5aa0c0f3c0ea016b3039574242 4.836888397664349

3 Likes
#7

According to your statistics, there are 4 more addresses as follows:
1.
wallet address: 0x87bedf6ad81a2907633ab68d02c44f0415bc68c1
relayer ens: tornrelayer.eth
cheating tx hash: 0x91f61e55128fbc7a846490797462b400d7121af3d77599cfab6214728e7a71b1

wallet address: 0x14812ae927e2ba5aa0c0f3c0ea016b3039574242
relayer ens: pls-im-poor.eth
cheating tx hash: 0x361ca6a5ece00d2749f78598626a09a3d4fc96d2e4b38a6bdc2504ea5d5e879a

  1. He was an early relayer before 2022-02-21 and did not stake TORN
    wallet address: 0x2209efc366594f813e1fcdd9401560a69f1575f4
    tx hash: 0xf6f63f9e898f0493a04765ea6e219b88f00742e3c26986566e53854f1aad9941

  2. I don’t know what’s wrong
    wallet address: 0xa0959536560776ef8627da14c6e8c91e2c743a0a

3 Likes
#8

I totally agree with this proposal.

Basically those relayers are doing free money (after deducting the minimum amount to stake) and set their fee extremely low to have better chance on the formula.

As mentioned in the proposal, we must reset their staked balance to 0 and increase the registry listing to at least 2000 TORN or even more. It will deter some of them to pay back 2000 * TORN price to register again.

So cheating relayers must register again.
And relayers that aren’t cheating and have a staked balance under 2000 TORN must be able to relay like usual.

2 Likes
#10

Added two additional violators, the other two were not registered - therefore did not break any requirements by processing withdrawals normally.

#11

Proposal is now live and deployed at:

1 Like