> For the complete documentation index, see [llms.txt](https://hinkal-team.gitbook.io/hinkal/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hinkal-team.gitbook.io/hinkal/technical-description/setup/eddsa-signatures.md).

# EdDSA Signatures

### EdDSA Signing

Spending from a Hinkal shielded balance is authorized with an **EdDSA‑Poseidon signature over the BabyJubJub curve** — the elliptic curve used inside Hinkal's zero‑knowledge circuits. This is distinct from the chain‑native ECDSA/Ed25519 keys used to broadcast transactions: the EdDSA key proves, in zero knowledge, that the spender owns the notes being consumed, without revealing the shielded key itself.

The spending keypair is derived deterministically from the user's shielded key, so no extra secret needs to be stored. The spending private key is `Poseidon(prefix, shieldedKeySignature)`, and the corresponding public key is the BabyJubJub point obtained by the standard circomlib derivation (`prv2pub`: `Base8 · clamp(blake512(prv)) >> 3`). Because it is a pure function of the shielded key, the spending key inherits the same protection — for WaaS wallets it only ever exists inside the secure enclave.

To authorize a transaction, the enclave signs a single field‑element message with EdDSA‑Poseidon, producing a signature `(R8, S)` where `R8` is a BabyJubJub point and `S` is a scalar. The signed message is bound to the proof through a public `message = Poseidon(messageSeed)` value, so a signature cannot be replayed against a different transaction.

Inside the circuit, an `EdDSAPoseidonVerifier` checks that `(R8, S)` is a valid signature on the signed message under the spender's BabyJubJub public key. A proof is only accepted when this verification passes, which is what cryptographically ties each spend to the holder of the shielded key.

This gives the shielded spend flow several properties:

* The spending key is derived from the shielded key, never stored separately
* Signing uses EdDSA‑Poseidon over BabyJubJub, matching the in‑circuit verifier
* The signed message is pinned to the proof, preventing signature replay
* Spend authorization is proven in zero knowledge — the key is never revealed on‑chain

### How EdDSA‑Poseidon Works

EdDSA is a Schnorr‑style signature scheme defined over a twisted‑Edwards curve. Hinkal uses the **BabyJubJub** curve with **Poseidon** as the hash function, in place of the SHA‑512 used by Ed25519. All arithmetic below is in the curve's prime‑order subgroup, with base point `B` (`Base8`) and subgroup order `n`.

**Key derivation.** The 32‑byte spending secret is expanded with a hash and *clamped* (low bits cleared, a high bit set) to produce the secret scalar `a`. The public key is the curve point

```
A = a · B
```

Because `A` is a scalar multiple of the generator, recovering `a` from `A` is the elliptic‑curve discrete‑log problem — computationally infeasible.

**Signing a message `M`.** Signing is deterministic — the nonce comes from the secret and the message, never from an external RNG, so a weak random source can't leak the key:

```
r  = H(secretNonceKey, M)        // deterministic per-message nonce
R8 = r · B                        // nonce commitment (a curve point)
k  = Poseidon(R8.x, R8.y, A.x, A.y, M)   // challenge binding R8, the key, and the message
S  = (r + k · a) mod n            // scalar response
```

The signature is the pair `(R8, S)`. The challenge `k` folds the message into the signature, so `(R8, S)` is valid only for that exact `M`.

**Verification.** A verifier recomputes the challenge `k` from the public values `(R8, A, M)` and checks the single curve equation

```
S · B  ==  R8 + k · A
```

This holds for an honest signer because `S · B = (r + k·a) · B = r·B + k·(a·B) = R8 + k·A`. Producing a passing `(R8, S)` without knowing `a` would require solving the discrete log, so a valid signature proves possession of the private key. (In practice the check is multiplied through by the curve cofactor `8` to rule out small‑subgroup points.)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://hinkal-team.gitbook.io/hinkal/technical-description/setup/eddsa-signatures.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.