#0 vm/execgno.land/r/gnops/valopers.Register(moul, moul (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., on-prem, g1manfred47kzduec920z88wfr64ylksmdcedlf5, gpub1pggj7ard9eg82cjtv4u52epjx56nzwgjyg9zqkwz64dupn9vk4dlm0zy8my8xzysgqulepavucq4kxgxf3djlmt2y0mxr6)
{
"__typename": "MsgCall",
"caller": "g1manfred47kzduec920z88wfr64ylksmdcedlf5",
"send": "",
"pkg_path": "gno.land/r/gnops/valopers",
"func": "Register",
"args": [
"moul",
"moul (Manfred Touron), gno.land contributor since 2022.\n\n1. Validator name: moul\n\n2. 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.\n\n3. Digital presence: https://gno.land/u/moul and https://github.com/moul\n\n4. Contact: already known by the gno.land team.\n\n5. 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.\n\n6. 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.\n\nSetup: 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.",
"on-prem",
"g1manfred47kzduec920z88wfr64ylksmdcedlf5",
"gpub1pggj7ard9eg82cjtv4u52epjx56nzwgjyg9zqkwz64dupn9vk4dlm0zy8my8xzysgqulepavucq4kxgxf3djlmt2y0mxr6"
],
"max_deposit": ""
}