walletbeat

Walletbeat now automatically deploys to IPFS via @orbiterhost, then updates ENS records.

Yes, it uses Helios as a light client when interacting with the chain.
Imagine 𝘯𝘰𝘵 using a light client in 2025.
Utterly inconceivable, especially for wallets, right?

The easiest static website and web app hosting. Built on /ipfs and /base

Contributor @ /walletbeat.

Censorship resistance requires privacy.

What sync committee do you use as a trust anchor in that? Merge block?

There is a mainnet checkpoint checked into the repo itself at
`deploy/helios/data/checkpoint`, and there's a CI workflow updates it every few days:
https://github.com/walletbeat/walletbeat/blob/beta/.github/workflows/helios-refresh.yaml

Helios is also started with the `--strict-checkpoint-age` flag, which makes it refuse to start if that checkpoint is too old:

VP Tech Gnosis, founder HOPR. I believe in empowerment of the individual through decentralization and privacy.

There is a mainnet checkpoint checked into the repo itself at
`deploy/helios/data/checkpoint`, and there's a CI workflow updates it every few days:
https://github.com/walletbeat/walletbeat/blob/beta/.github/workflows/helios-refresh.yaml

Helios is also started with the `--strict-checkpoint-age` flag, which makes it refuse to start if that checkpoint is too old:
https://github.com/walletbeat/walletbeat/blob/5ca663f98b5511caf08d5ee2bf67e466f2fd85a1/deploy/helios/helios-wrap.sh#L30-L36

I don't think you need governance here. My sense is that you could:
- At time time T, load Helios with checkpoint from time T-1 and run it in a sandbox that records all the network traffic.
- Look at the checkpoint for time T it produced.
- Re-run Helios in a zkVM with a clock set back to time T. Block its external network access, but inject the incoming traffic you had recorded (behavior and incoming/outgoing network traffic should be exactly deterministic).
- Re-verify that it produced the same checkpoint for time T.
- Submit new checkpoint + proof of correct Helios execution from the zkVM.
This effectively means that if you trust the checkpoint at time T-1 and that you trust Helios is correctly implemented and that the zkVM is as well, you can now also trust the checkpoint at time T.

I'm curious what's the best way to guarantee the correctness of that trust anchor. I guess ultimately it would be reproducible builds that then get signed off by some governance mechanism (multisig would be an easy form of that) which is also in control of the ENS domain and can update once quorum has been reached?