I was going through Sign Protocol's documentation and something kept pulling at me. The protocol supports three different signature standards. ECDSA, EdDSA, and RSA. That sounds like a flexibility advantage, and maybe it is. But the longer I sat with it, the more I started thinking about the person on the other end of that credential and what they actually know when it arrives.
The credential looks the same regardless of which method produced it. That is the part I could not stop thinking about.
Sign Protocol is an attestation system. Someone issues a signed data record, anchors it to a chain or a storage layer like Arweave, and anyone can theoretically verify it. The use cases they point to are broad. Identity, audit proofs, cross-chain reputation. The word sovereign shows up a lot in their materials. Whether the current system actually lives up to that framing is a separate question I keep sitting with.
To understand the signature problem it helps to follow what actually happens when an attestation gets made.
An issuer builds a schema, which is basically a template for what fields the record will carry. They fill it in, sign it, and it gets stored somewhere. On an EVM chain like Ethereum or BNB Chain, the record goes through a smart contract. Off-chain records go to Arweave or IPFS.
Here is where it gets interesting. On EVM chains there is no algorithm choice happening. Ethereum runs on secp256k1 ECDSA and the smart contract recovers the attester address through ecrecover, which only works with that one algorithm. So every EVM on-chain attestation is ECDSA by default. The chain decides that, not the protocol.
On TON it is Ed25519 because that is what TON uses natively. Solana is referenced in their documentation as something coming but I could not find a live implementation. In every on-chain case the host chain is picking the scheme. Sign Protocol is inheriting that choice, not making one.
The off-chain layer is different. There is no precompile forcing anything so the design is genuinely open. Older posts from the team describe it as able to support RSA, other ECDSA variants, EdDSA, even zero knowledge proofs as a form of consent. The phrasing they used was can easily add support for, which to me reads more like a design ambition than something you can go use today.
Looking at the SDK the only off-chain signing option I could find documented was EIP-712, which is still secp256k1. Whether RSA is actually available somewhere in the tooling I could not confirm. I am not certain it is.
So the multi-algorithm story is architecturally plausible but practically thin, at least from what is publicly documented.
Now the part that kept me coming back to this. Even if all three schemes were fully deployed and working, what does the verifier actually see when a credential arrives?
I went through the attestation struct and the schema struct in the contracts. Neither has a field for the signature algorithm. There is a field for where the data lives, one for the attester's address, timestamps, revocation status. Nothing that says this was signed with EdDSA or this was RSA-2048. The schema definition is just a free-form string. The protocol does not standardize an algorithm identifier anywhere that I could find.
For on-chain EVM attestations that is not a real problem because there is only one option and the chain enforces it. But for off-chain attestations the receiver either has to know through some separate channel what scheme was used or the application has to sort it out on its own. The protocol does not hand that information over.
This matters more than it might seem. ECDSA uses a random nonce every time it signs something. If the random number generator was weak when that signature was produced, the private key can potentially be recovered from the signature itself. That has actually happened in deployed systems. EdDSA does not have that problem because the nonce is derived deterministically from the key and the message. There is no randomness to fail. RSA works differently again and produces signatures so large that verifying them on-chain is not really practical.
These are meaningfully different security profiles. A receiver looking at an off-chain attestation and not knowing which scheme produced it is implicitly trusting whichever one the issuer chose. If it was ECDSA and the issuer had a bad RNG moment, the guarantee is weaker than it looks. The credential gives no signal either way.
I do not think Sign Protocol is uniquely bad here. A lot of credential systems handle algorithm transparency poorly. But a protocol positioning itself around government-grade trust infrastructure probably needs to be more explicit about this than most.
I also could not find a published security audit. OtterSec comes up in their materials but as a user of the system for publishing their own audit reports, not as someone who audited Sign Protocol's contracts. That might have changed. I just did not find it.
The thing I keep returning to is simple. Flexibility across signature schemes is only useful if the receiver can tell which scheme they are dealing with. Without that, the flexibility mostly benefits the issuer and the receiver is left making assumptions. In a trust system, that feels like the wrong side to leave in the dark.