TezSign: tz4-ready hardware signer for Tezos baking

[Primate411]

The Problem

Small to medium-sized Tezos bakers lack a dedicated, affordable, and secure hardware solution. They are forced to choose between:

• Complex software signers with a higher risk profile.
• Expensive, general-purpose hardware wallets that are not optimized for the unique demands of 24/7 baking.

With the advent of tz4 signature aggregating signing in the “T” protocol, small to medium-sized bakers no longer have the Ledger Nano line of products to use as their affordable hardware signers.

The upcoming Tezos “T” protocol will revolutionize key management with its 4-hour cooldown for consensus key switching. This opens the door for a new class of DIY, specialized, single-purpose signing devices like SBCs.

The Solution

TezSign!

We introduce TezSign: a dedicated, DIY Hardware Security Module (HSM) designed from the ground up to provide robust security through its specialized, single-purpose design for bakers, at a hardware cost under $20.

It is a single-purpose “baker companion” that does one thing perfectly: it signs baking operations securely and rejects everything else.

Simple, Focused, and Accessible

Plug-and-Play Security: A headless, low-power device. It’s USB-powered and managed by a simple utility app on the baker’s machine, ensuring a minimal footprint and effortless setup.

Radically Affordable:

By leveraging inexpensive and widely available Single-Board Computers (SBCs), we make cheap, robust security accessible to every baker.

Sample target devices: RADXA ZERO 3W and RPI ZERO 2W

Uncompromising, Purpose-Built Security

Baking Operations Only: TezSign is hard-coded to sign only blocks and attestations. It will categorically deny any other transaction request (e.g., fund transfers), completely eliminating the risk of a compromised baker machine draining your wallet.

Future-Proof Cryptography:

To conform with the latest developments of the Tezos protocol, we will provide BLS-only signatures.

A New Paradigm: Resilience Over Recovery

Designed for Protocol T: Our “no recovery” philosophy aligns perfectly with the new protocol. Keys are generated on-device and are not meant to be backed up with a seed phrase, making TezSign the ideal consensus/companion device.

Eliminates Catastrophic Penalties:

If a baker wants to move to another device while the old one is still in use, instead of restoring a backup, they simply generate new keys on the new hardware. This workflow eliminates the risk of double-baking or double-attestation.

Multi-key Baking:

A baker can load his or her consensus and companion keys on the same TezSign SBC. It’s possible to run multiple bakers on the baker machine with multiple consensus and companion keys.

How does this product work in practice?

1. A baker purchases an SBC for under $30 along with an SD card
2. Baker burns in SD card
3. Baker connects SBC via USB to baking machine
4. Baker runs tezsign new-key baker on the baking machine
5. Baker is ready to attest blocks

What happens if the baker needs to shut down baker?

The baker boots up the baker, plugs in the SBC and runs tezsign unlock ...

What happens if the TezSign SBC is stolen?

The attacker obtains encrypted version of baker’s consensus private key. The baker rotates consensus keys and continues to bake safely.

Community & Go-to-Market

Strategic Go-to-Market: Our goal is to have TezSign ready for the deployment of the “T” protocol.

Tinkerer-Friendly Foundation:

The core software is written in highly-optimized Go, making the code base transparent, easy to audit, and welcoming for community developers to build upon, customize or even fork.

The Ask & Funding Strategy

We are seeking funding to accelerate the core development, testing, and preparation for a community launch. We ask for 20,000 XTZ to deliver a fully working product, ready to use in production.

This initial funding is designed to kickstart the project and reach key milestones, making it production ready but not fully feature rich, yet. We anticipate it will be subsidized by TzC donations and other funds as needed to carry the project through to a fully-realized feature set.

Team Information

Name: Primate & V from Tez Capital
Email or contact method: .primate & .v_alis.is on Discord
Geographic location: Florida, USA
Are you applying on behalf of a company, or as an individual:
If company, provide company name and website: GrokTech LLC https://groktech.xyz
Name of project or idea: TezSign
Detailed description of your project or idea and why you believe it deserves funding: (included above)
What type of background or experience do you have and your team have in building out a project like this: We have been building in the Tezos ecosystem since 2021. Our products include: TezBake, TezPay, TezGov, TezPeak, TezWatch and Starlords.app
Social handles of project, if any: https://x.com/TezCapital/
Funding amount being requested (please make sure the DAO treasury can currently support it, suggested range is 500–20,000 tez depending on project requirements and value):
Tez address to be funded (please verify accuracy): 20,000 @ tz1aLN3iQ9SYex3tdUuvUwcb6DJYR8F9yMLP
Proposed goals/GPIs to deliver for the requested funding (funding may be broken into two tranches, with final half distributed after some proven deliverables):

Parting words…

Cutting off Ledger baking access in future proposals, once only tz4 is usable, has the potential to knock off many small and medium bakers, lowering our validator numbers and removing the accessible baking mantle from the blockchain.

We believe that having multiple cheap hardware signers ready for the “T” protocol, to use with TezBake or directly with Octez, gives us the best chance of retaining the most small and medium bakers.

[KevinMehrabi]

I strongly support this!

[RichAyotte]

How is this different than Nomadic Labs / Tezos RPI BLS signer · GitLab and Aggregated Attestations: A Heads Up for Bakers - #30 by VincentPoulain?

[Val]

That’s a great question. First, just to clarify, both the GitLab repository and the forum post you linked refer to the same project: the Nomadic Labs RPI BLS signer. As of now, it’s the only remote signer of its kind, and that’s the gap we’re looking to fill.

Our project is designed slightly differently.

• Headless Operation: Our signer is intended to be fully headless, meaning no screen or UI is required on the device itself. This significantly lowers the cost of the hardware and makes it easier for users to tinker with.
• Multi-Key Management: A core feature will be native multi-key support, allowing a baker to manage several key pairs on a single device instead of being limited to one pair.
• Optional Auto-Unlock: For ease of use, we want to offer an optional feature to automatically unlock designated keys when the device powers on.

• The Nomadic Labs signer communicates over TCP/IP, which is flexible but can add security complexity by potentially requiring a firewall.
• Our goal is for our signer to communicate over the raw USB bus. This approach avoids the need for a network stack entirely, which can create a more direct, sandboxed, and arguably more secure connection without needing a firewall. (Please note: This USB implementation is our current research focus. We have successfully tested TCP/IP and serial backends, but the raw USB functionality is still being validated.)

[RichAyotte]

Good to see options.

I like the epaper display though. Seeing various baking details at a glance and being able to take action with the touchscreen without needing to plug in a keyboard and monitor is a convenience that’s worth the money.

[Val]

I like the epaper display though. Seeing various baking details at a glance and being able to take action with the touchscreen without needing to plug in a keyboard and monitor is a convenience that’s worth the money.

That’s the thing—you wouldn’t have to. You would just manage it from your baker machine, which already has all the necessary peripherals.

Imagine:

> tezsign unlock baker-key1 baker-key2
Please provide the password: ********
Keys unlocked!
> tezsign generate-key baker-key3
Generate new key: baker-key3 tz4xXxXxXx...

Note: the above is a mockup/concept, not the final, functional command-line interface.

[RichAyotte]

Isn’t providing full access to the signer from the baker increasing the attack surface? I’d feel more comfortable knowing the baker can’t ever muck around with the signer.

[Val]

Isn’t providing full access to the signer from the baker increasing the attack surface? I’d feel more comfortable knowing the baker can’t ever muck around with the signer.

That’s a valid concern, and it’s precisely why the system is designed with strict limitations. It’s important to clarify that the baker does not have “full access” to the signer. The permissions are intentionally narrow:

1. The baker can only request the generation and unlocking of keys.
2. Those keys are scoped specifically for baking; any other type of signing request would be denied.

This leads to a security debate: are you more comfortable with your signer being potentially accessible over the network via IP, or with the baker having a few highly restricted local commands?

While I’m admittedly biased, but from my experience a simpler, more limited interface is generally better for security.

[TezosEcosystemDAO]

Proposal is live, vote here! : TezSign Proposal

[CanadianBakin]

TezSign is an excellent project which I fully support. I believe a dedicated and affordable hardware solution for bakers is integral to the Tezos ecosystem.

[TezNebraska]

Thanks, again, TezCapital, for your contributions to the Tezos community. You have my vote.

[Primate411]

Thanks to everyone that voted for TezSign! Thanks to everyone who participated!