A decentralized privacy protocol with integrated staking rewards on Ethereum, developed during the Web3 camp at the Petnica Science Center, in collaboration with Mihailo Trajkovic.
Staker Mixer is a decentralized protocol based on the idea of Tornado Cash, with an added staking mechanism. Users deposit ETH into the protocol, and while their funds remain locked, they automatically earn rewards through staking.
On the Ethereum network, all transactions are public, which created the need for solutions that preserve privacy. This is where mixers come in - protocols that make it impossible to link the address used for depositing funds with the address used for withdrawing them. The level of privacy in mixers depends on the number of users, as well as how long funds remain in the protocol.
Our project integrates mixer logic with staking. The idea is to motivate users to keep their funds in the protocol longer by rewarding them based on the time they stay staked. This increases privacy, because a larger and more stable deposit pool makes transaction linking significantly more difficult.
When a user deposits ETH into the mixer:
-
the deposit is automatically sent to staking,
-
the funds remain locked until the user decides to withdraw,
-
upon withdrawal, the user receives the initial amount plus the staking reward earned.
The main challenge is to distribute the reward without compromising user privacy and without revealing which specific withdrawal corresponds to which deposit.
Tornado Cash is based on a Merkle tree and zero-knowledge proofs.
1.) The user chooses two secret values: a secret and a nullifier.
2.) A hash is computed from these values, and this hash—together with the ETH deposit—is inserted into the Merkle tree.
3.) When withdrawing, the user uses a ZK proof to show that:
-
they know the values (secret + nullifier) corresponding to one of the Merkle tree leaves,
-
they know the root of the tree,
-
while not revealing which leaf belongs to them.
We add one more element: the timestamp of when the deposit was made.
-
As before, the user sends hash(secret, nullifier), but now also a hashed timestamp, which is stored in the Merkle tree.
-
During withdrawal, a ZK proof is generated again, but now the leaf hash is computed from three values: the secret, the nullifier, and the timestamp.
Additional requirement: The user must also prove that they are entitled to a higher payout (e.g., 1.1 ETH if they deposited 1 ETH), which means they must prove that their funds have been locked in the protocol long enough
The deposit timestamp is known at the moment of deposit, but it is not revealed during withdrawal. Instead, the user publicly submits:
-
t – some time close to the current moment,
-
Δt (delta t) – the interval they claim the funds have been locked.
The ZK proof verifies that:
timestamp + Δt < t without revealing the actual timestamp.
At the smart-contract level, it is checked whether, in the interval [t − Δt , t], enough yield was accumulated to justify the amount the user wants to withdraw.
One of the important upgrades to the system is integration with existing staking protocols (e.g., Lido), which enables:
-
more stable reward generation,
-
automated management of staked ETH.