κασσάνδρα.eth kassandraoftroy

Seed-derived note secrets for Privacy Pools v1 and Tornado Cash

This document explains how Kohaku derives private note secrets from a seed phrase using deterministic signatures. It is for wallet implementers who need to reproduce those notes, integrate a hardware wallet, or recover an existing wallet. It includes exact encodings, test vectors, and a runnable verifier.

Why derive secrets from signatures?

Hardware wallets generally cannot run the required zero-knowledge prover, so the host needs the note secrets to create proofs. A compatible hardware wallet can produce a deterministic signature without exporting its seed or account private key. The host derives the note secrets from that signature and proves off-device. The exported signature is therefore sensitive note material, while the account private key stays on the device.

Scope and conventions

Tornado Cash Governance Proposal: Add 0.01, 0.03, 0.3, 3, and 30 ETH Anonymity Pools

Author: kassandra.eth Network: Ethereum Mainnet Type: Instant / Protocol Parameter — New Pool Deployments

Summary

Rethinking Ethereum Wallets: A New Approach

Ethereum's account and wallet model for end users has barely evolved since its early days. The assumption that "a user account == a single address" (usually an Externally Owned Account, or EOA) is the original sin of Ethereum wallet UX. This outdated paradigm is holding back innovation and making Ethereum needlessly complex, cumbersome, and privacy-leaking for users.

When you open MetaMask, Rabby, Rainbow, or any other browser wallet, you see a dropdown list of EOAs--single-address accounts that you must manually switch between. Each address is treated as an isolated entity/identity/namespace, and is utilized as a separate signer and transaction originator. The result is that users are forced to manage their assets and interactions at the individual address level, rather than at a more abstract account level.

Even more modern smart contract wallets (such as Safe) still model a user "account" as a single address. These wallets give us _account abstract

Obol DVT final setup

Prerequisites

ubuntu machine with docker
have charon-distributed-validator-node repo installed
completed DKG
EL client + lighthouse synced and running

Charon folder

Step 0 - Introduction

This is a step-by-step guide to staking on the Ethereum mainnet via Reth Execution Client and the Lighthouse Consensus Client. It is based on the following technologies:

Server: Ubuntu v20.04 (LTS) x64
Execution Client: Paradigm's Reth
Consensus Client: Sigma Prime Lighthouse

This guide is a fork and slight adaptation of Somer Esat guide here so that it works with the new Reth Execution Client. It is intended for stakers familiar with Somer Esat style staking setup who want to try out Reth Execution Client. It also relies heavily on info you can find in the Reth Book here

	type Vault @entity {
	id: ID!
	blockCreated: BigInt!
	timestampCreated: BigInt!
	manager: Bytes!
	address: Bytes!
	uniswapPool: Bytes!
	token0: Token!
	token1: Token!
	feeTier: BigInt!

	# @version 0.2.16
	"""
	@title Liquidity Gauge v5
	@author Arrakis Finance
	@license MIT
	"""

	# Original idea and credit:
	# Curve Finance's LiquidityGaugeV4
	# https://github.com/curvefi/curve-dao-contracts/blob/master/contracts/gauges/LiquidityGaugeV4.vy

	# @version 0.2.16
	"""
	@title Liquidity Gauge v4
	@author
	@license MIT
	"""

	# Original idea and credit:
	# Curve Finance's LiquidityGaugeV4
	# https://github.com/curvefi/curve-dao-contracts/blob/master/contracts/gauges/LiquidityGaugeV4.vy