1BE4A5A1A7F218…3599CC91E406

Arguments · 5

1. #1moul
2. #2moul (Manfred Touron), gno.land contributor since 2022. 1. Validator name: moul 2. Networks and AuM: gno.land only. Ran public full nodes on earlier gno.land networks (betanet, pearl) and currently validating on onyx-1. No assets under management: self-funded and self-operated, not a staking service. 3. Digital presence: https://gno.land/u/moul and https://github.com/moul 4. Contact: already known by the gno.land team. 5. Why validate on gno.land: I have contributed to gno.land since 2022 and run parts of its infrastructure daily. Validating on hardware I own, with the consensus key held in a hardware signer, is the setup I want the network to be able to rely on, and operating it myself is how the operational gaps a cloud node hides get found and fixed. 6. Contributions: long-standing contributor to gnolang/gno, author of developer tooling around it (gnopie, gnoblog, gnohome and others) and of several realms deployed on mainnet, GovDAO T1 member. This validator runs on-premises to help prove out the on-prem validator architecture the team is standardising on, and I report back what breaks. Setup: on-premises bare metal, Debian 13, consensus key held in a YubiHSM 2 fronted by tmkms, behind a sentry node. The validator accepts no inbound connections from the public network and never dials it.
3. #3on-prem
4. #4g1manfred47kzduec920z88wfr64ylksmdcedlf5
5. #5gpub1pggj7ard9eg82cjtv4u52epjx56nzwgjyg9zqkwz64dupn9vk4dlm0zy8my8xzysgqulepavucq4kxgxf3djlmt2y0mxr6