Upcoming Relayer election mechanism

Absolutely should not be optimized for whales. Should be optimized for highest level of privacy

How do we create trustless relayers?

If relayer network is trustless first and then it turns out whales are the only ones who can then afford to operate, great. Then it’s skewed for whales. That’s fine, but only if privacy is #1

1 Like

[quote=“acegilz, post:10, topic:28”]
What is the logic of needing to have a voting for each new relayer to be added?[/quote]

Agree, it should be changed so that anyone that posts TORN stake can become a relayer.

1 Like

We tried to do this in the initial relayer network design but this approach has a lot of problems. If the fee goes msg.sender, relayers start to frontrun each other and also compete with generic frontrun bots. In the end only a single transaction goes thru and all others revert and relayers lose funds. We were unable to solve those problems and went with different design where a user has to choose which relayer gets the fee in advance.

The problem is, if someone posts a transaction on chain, he will likely gets frontrun by bots and loses fee, but if nobody posts this transaction the frontrunners will never know about it. In theory frontrunners can be used as a relayer network, if we find a way to broadcast transactions to them without losing funds on reverts.

1 Like

I see an issue with this. Providing stake does not grantee quality of service. If the relayer can’t be kicked out (or slashed) by governance, he has no incentive to provide a good service and can be down or buggy.

It is not perfect, but it’s a good start for decentralization. It can be upgradeable to improve in the future.

The UI can do basic uptime and health checks and warn users if fees are too high.


This is a pretty interesting approach. It does assume front-runners exist.

Don’t you still need a “first broadcaster” to relay the transaction to the mempool? In that case, the concept of needing a relayer remains.

I think the model right now of having relayers is simple and has few security/UX risks. Its not perfect, as relayers know the IP address of the submitter, but its decent.


why is this still on hold??? Please someone update and make the proposal :pray:t3::pray:t3:

No one is referring about abolish the kick/slashing mechanism. There may be a way to kick users via proposal vote, in case relayers are consistently down or performing bad. IMO in case a relayer is slashed (instead of himself leaving via remove() ), there should be a penalisation, for example 20% of the staked TORN.
However, that governance voting should NOT need to apply to every new relayer that exists… additions should be automatically accepted, given the fact relayers has TORN funds to commit

smart contract needs to be reworked first to allow anyone to join

It’s literally just remove one line.



Well, the build fails on your PR, so not just one line. But I agree, it’s not very difficult. The team is currently fully focused on updating tornado trees contract to fix mining, so it would be cool if someone from the community helps with this proposal to speed it up.

Here’s what needs to be done before deploying:

  • write missing tests
  • ensure that a relayer is able to enter and exit
  • add upgradability proxy (and test it)
  • add and test governance proposal contract
1 Like

Would it be possible to have a sort of pool of relayers, anyone can join (or only people with TORN locked up). The pool’s members get randomly assigned withdrawals. The reward / n goes to the n members that processed withdrawals in the period X.
That way there is no competition, and you avoid passive members getting rewards for nothing.
I’m thinking like for certain restaurants where the tips get pooled and split evenly among all staff, to avoid the atmosphere of competition within the team.
What do you think?

1 Like

Would it be possible to have a sort of pool of relayers, anyone can join


(or only people with TORN locked up)

For what purpose, tho? Just to create a sink in circulating TORN supply?

Normally, staking mechanisms are implemented to disincentivize bad behavior. However, there’s really no way for relayers to misbehave here

Introducing a min TORN threshold to relay would just create barrier to entry that would be skewed to benefit whales. Kind of pointless when arbitrarily staked TORN wouldn’t actually secure anything

That way there is no competition

Competition is actually a good thing here

Yes, relayers are currently in competition with each other, which probably seems like a bad thing for relayers who want to collect higher fees. But it’s a good thing for the end user because it prevents relayers from creating a collective monopoly to set artificially high fees without being challenged by competition

What do you think?

It might work if a pool of relayers operate what would technically be a single relayer node together. Then that single relayer node would compete with all the other relayers (just as all relayers do now)

TBH tho, this wouldn’t intrinsically align any interests for the sub-relayer pool participants to incentivize this behavior. There’d have to be some kind of external market force to make this economical

For example, if a relayer node operator really wanted to participate in governance with more TORN to vote, then they might be willing to evenly distribute their earned relayer fees with anyone who delegates X amount of TORN to them for voting. This would kind of simulate a sub-relayer pool where membership and fees are granted to TORN stakers

1 Like

For point 1: staking TORN. YOu’re right, why not remove. Anyone can spin up a docker on a VPS and participate!

For the incentive, sorry, maybe I didn’t explain the pool well.
I didn’t mean relayer pools / delegated voting systems etc. I meant basically all relayers in a pool from the user’s perspective.

Relayers competing can still do informal price fixing. Eliminating competition allows more fairness to the people running a relayer (no race to the bottom fees) and to the users (no price floors set tacitly). One could set a base relayer fee through governance, and then the pool of people actually running the relayers get a monthly payout of (Total fees generated ) /(individual relayers used during the month). Ie, you only get an even cut if you actually facilitated a transaction. If you didn’t get a transaction this month, you may be selected next month.

If the pool of relayers is too large, ie you never get a transaction to process, then people will drop out, and reduce pool size, increasing average rewards.

And so people are incentivised to run relayers (good for decentralization), but are more of a plumbing infrastructure function. It’s more of a collective incentive to support the project.

So on a UI side, people just see “withdraw” and choose “via relayer - current fee fixed by governance is 0.1%” and then the relayer is chosen randomly from the pool - but all those processing transactions benefit at the end of the month.


Locking TORN also provides a primitive sybil resistance

But what is so bad if one actor happens to operate two elected relayers? Nothing really afaict. Just might feel a little unfair to other potential relayers who didn’t get elected

Now maybe if one actor happens to run all elected relayers. And then takes all relayers offline at the same time. That would be a problem

Which, to be fair, that alone might actually be a good enough reason to incorporate TORN staking and slashing. If your relayer is elected, but goes offline and is challenged, then you forfeit some stake. A provable challenge tx would just need to be submitted (potentially alongside a
failed withdraw request) in order to slash the relayer

There’d have to be a limit on frequency of challenge txs though so down relayers don’t get recursively slashed into oblivion. So maybe max 1 slash/hr or something like that

What if one actor submits 1000 relayers? A few posts above users wanted relayer list to not require governance vote, so anyone would be able to add relayers in bulk without stakes.

Proving onchain that relayer is offline is a hard problem. How do you prove whether user poorly sent his request or relayer poorly received it?

1 Like

What if one actor submits 1000 relayers?

Okay, so at the very least maybe requiring stake is more about anti-spam than anti-sybil. That’s a good enough reason to require it. I’m starting to come around to the idea

How do you prove whether user poorly sent his request or relayer poorly received it?

There’d need to be a relayer-watcher network where users submit withdraw requests to specific relayers (same as they do now) while simultaneously broadcasting watcher requests to the network. So one relayer would be declared as the recipient of the withdraw request while all other relayers would operate as watchers for the request

When requests are broadcasted, watchers are responsible for writing to some consensus layer (1) the requested relayer’s address, (2) the requested tornado pool - token and denomination; (3) the requested withdraw address, and (4) a counter for the number of times 1,2,3 have already been successfully relayed

If all watchers successfully document a request, then it can be proven the user successfully sent it. And if the request isn’t fulfilled by the relayer, then it can be proven through inference that the relayer poorly received the request

In the event a relayer does fail their duty in this way, anyone with stake can then act as a challenger to the relayer. If the relayer fails the challenge, they forfeit their stake to the watchers. Conversely, if a relayer is falsely challenged, the challenger forfeits a stake to the relayer

Design issues to be resolved this model:

  • What’s the incentive for users to broadcast to watchers?
    • Maybe they also get a share of forfeited stake if a relayer fails and a challenge is won
  • Do watchers need to also be relayers?
    • The two roles could probably be separated, but overlap if a single node wants to operate as both
  • To what consensus layer do watchers write?
    • Ethereum mainnet would be too expensive for all watchers to consistently write
    • A childchain/POA network could work - but then states would need to be safely transported to the mainnet challenge contract where stake is held at the time of the challenge

Is there any update on this? Almost 6 months have passed and unfortunately there is still no way of being a relayer if you are not from team Tornado. thks

There’s a more active thread on design started by @bt11ba here: