How We Use Ed25519 Signatures to Give Users Cryptographic Proof Before They Send Crypto

Chlora Tempra — Tue, 21 Apr 2026 10:19:50 +0000

Most instant crypto swap services work on pure trust.

You visit the site, get a deposit address, send funds, and hope the service sends back what it quoted. There's no cryptographic commitment before you transact. If something goes wrong — wrong rate applied, address substituted, service disputes the terms — you have nothing verifiable to stand on.

We wanted to fix that. Here's how we built a pre-payment signature system for 0trace using Ed25519, and why it matters for users doing private crypto swaps without accounts or identity disclosure.

The Problem: Trust Without Verification

In a standard instant swap flow:

User requests a quote
Service returns a deposit address and quoted amounts
User sends funds
Service executes the swap and sends payout

Step 3 is the trust cliff. At the moment the user sends funds, they have no binding commitment from the service. The rate could change, the deposit address could theoretically be substituted, or a dispute could arise about what terms were actually agreed.

For a service that stores no user accounts, no email addresses, and no transaction history — there's no customer service ticket to open. The anonymity that protects users also removes the standard dispute resolution fallback.

We needed a different trust mechanism. One that doesn't require identity, accounts, or trusting our own servers after the fact.

The Solution: Signed Order Documents

Before a user sends funds, we generate a Guarantee document — a JSON object signed with our Ed25519 private key. After the swap completes, we generate a Receipt with the settled transaction details, also signed.

Both documents can be verified by anyone, at any time, offline, against our published public key. No API call. No server contact. Just the document, the signature, and the public key.

Here's what a Guarantee contains:

{
"orderId": "abc123...",
"createdAt": "2026-04-01T12:00:00Z",
"fromAsset": "btc",
"toAsset": "xmr",
"depositAddress": "bc1q...",
"payoutAddress": "4...",
"fromAmount": "0.01",
"toAmount": "1.842",
"rateType": "FIXED",
"expiresAt": "2026-04-01T12:10:00Z"
}

The signature covers the entire payload. If any field is altered after signing — deposit address, quoted amounts, payout address — the signature verification fails.

Why Ed25519

We chose Ed25519 (Edwards-curve Digital Signature Algorithm over Curve25519) for several reasons.

Small signature size. Ed25519 signatures are 64 bytes. RSA-2048 signatures are 256 bytes. For documents that users might store or transmit, this matters.

Fast verification. Ed25519 verification is extremely fast — we run it client-side in the browser using the standard Web Crypto API with zero perceptible latency.

Strong security properties. Ed25519 is not vulnerable to timing side-channel attacks by design. It also doesn't require a random nonce during signing, which eliminates an entire class of implementation bugs that have compromised ECDSA deployments (see: the PS3 key extraction, the Bitcoin Blockchain.info vulnerability).

Wide browser support. SubtleCrypto in modern browsers natively supports Ed25519 key import and signature verification. No external crypto libraries needed for the verification page.

Deterministic. The same private key + message always produces the same signature. This makes testing and auditability straightforward.

Implementation: Signing

The signing happens inside our signer service, which is physically isolated from the main application server. The private key never touches the web-facing application layer.

import { createPrivateKey, sign } from "crypto";

function signOrderDocument(payload: object, privateKeyHex: string): string {
const privateKey = createPrivateKey({
key: Buffer.from(privateKeyHex, "hex"),
format: "der",
type: "pkcs8",
});

const message = Buffer.from(JSON.stringify(payload));
const signature = sign(null, message, privateKey);

return signature.toString("base64url");
}

The payload is serialized to JSON with deterministic key ordering before signing, so the verification side always produces the same byte sequence.

The signed document returned to the user is the payload plus the base64url-encoded signature:

{
"payload": { "...order fields..." },
"signature": "base64url-encoded-signature"
}

Implementation: Verification

Verification runs entirely in the browser. The user downloads the document (or pastes it), and the page verifies the signature against the hardcoded public key using SubtleCrypto:

async function verifyDocument(document) {
const { payload, signature } = document;

const publicKeyBytes = hexToBytes(PUBLIC_KEY_HEX);

const cryptoKey = await crypto.subtle.importKey(
"raw",
publicKeyBytes,
{ name: "Ed25519" },
false,
["verify"]
);

const message = new TextEncoder().encode(JSON.stringify(payload));
const sigBytes = base64urlToBytes(signature);

const valid = await crypto.subtle.verify(
{ name: "Ed25519" },
cryptoKey,
sigBytes,
message
);

return valid;
}

No network requests. No server involvement. The public key is published on our website and hardcoded in the verification page — users can check it independently.

What This Gives Users

Before sending funds, a user can:

Download the Guarantee document
Open the /verify page (or run verification locally)
Confirm the signature is valid against the published public key
Confirm the deposit address in the document matches what the UI shows
Confirm the quoted amounts and payout address are exactly what they agreed to

If any of those checks fail — document was tampered with, address was substituted, amounts were altered — the signature verification fails. The user has a clear signal before committing funds.

After the swap completes, the Receipt provides the same cryptographic proof for the settled transaction, including the payout transaction hash when available.

Why This Matters for Privacy-Focused Swaps

0trace is built for users who want to swap crypto without accounts, without KYC, and without leaving a data trail. The absence of an account system — which protects users — also removes the standard dispute resolution path that account-based services offer.

Signed documents are the alternative trust mechanism that works without identity. A valid Ed25519 signature on a Guarantee is proof that is independent of our servers. It doesn't require us to look anything up. It doesn't require the user to identify themselves. The math either checks out or it doesn't.

This is what "trustless" should mean in practice — not "trust that we're honest," but "verify that the commitment is real before you send."

The Key Management Side

The signing private key lives exclusively in the signer service, isolated on a separate physical machine. The main application server requests signed documents via an internal API — it never has access to the signing key itself.

Key rotation is supported: the published public key fingerprint is versioned, and historical documents remain verifiable against the key that was active at signing time.

Limitations and Trade-offs

Float rate Guarantees are necessarily indicative. For FLOAT rate orders, the Guarantee captures the quoted amount at order creation time — but the final amount is determined at deposit detection, when the live rate is applied. The Guarantee for a float order commits to the deposit address and payout address, but the amounts are preview-only until the deposit lands.

Fixed rate Guarantees are binding for the lock window. Once the lock expires and falls back to float semantics, the amount commitment no longer holds.

We document this distinction explicitly via the rateType field, so users can evaluate what exactly they're getting a commitment on.

Open Questions

A few things we're still thinking about:

Should Guarantees be publicly auditable? Right now, verification is private — only the user with the document can verify it. There's an argument for a transparency log where all issued Guarantees are published (like Certificate Transparency for TLS), allowing anyone to audit that we're not issuing duplicate guarantees for the same deposit address.

Should the public key be on-chain? Publishing the signing public key to an immutable on-chain record would make it harder to silently rotate to a compromised key. Currently it's web-published, which means it's only as trustworthy as our web infrastructure.

Both would increase auditability at the cost of complexity. Happy to hear thoughts in the comments.

The verification page is live at 0trace.io/verify. If you want to test the flow, create a small order, download the Guarantee, and run it through the page — or implement your own verifier against the published key.

Reference: SubtleCrypto verify — MDN

DEV Community: Chlora Tempra

[Boost]

How We Use Ed25519 Signatures to Give Users Cryptographic Proof Before They Send Crypto

How We Use Ed25519 Signatures to Give Users Cryptographic Proof Before They Send Crypto