// HONEST COMPARISON

What Fidacy is not.

Most of what you could use instead of Fidacy is good, and necessary. The point of this page isn't to say the alternatives are wrong. It's to show, honestly, where each one is the right call, and the one thing none of them give you: a neutral, signed verdict the other side can verify without trusting you. We'll tell you when not to use Fidacy too.

vs. {{ c.name }}

{{ c.themLabel }}

{{ c.themBody }}

FIDACY (SIGNED) ⬡

{{ c.fidBody }}

// WHEN THEY'RE RIGHT

{{ c.when }}

// WHERE ONLY FIDACY FITS

{{ c.only }}

// THE HONEST STANCE

{{ c.stance }}

The one thing none of them give you.

Content guardrails, in-house logs, OAuth, proof-of-human: each is the right tool for its job, and several of them belong in your stack alongside Fidacy. But none of them produces the one artifact that decides an agentic transaction with a party that doesn't trust you: a neutral, signed verdict on who the agent is, whose it is, and whether the action was authorized, verifiable by anyone, on any rail, in any jurisdiction, with no trust in us required. That artifact is the whole product. Run it yourself and check the signature.

And the verdict isn't only readable, it's binding. When the action is a payment, an ALLOW issues a short-lived grant the executor verifies before money moves. A DENY means no grant and no money. Every decision lands in a hash-chained audit whose head is anchored to Bitcoin, so no party, including Fidacy, can rewrite it. One install, npx -y @fidacy/mcp, ships both.

Run a live verdict → Try the payment firewall → Read the integration docs →
// WHEN NOT TO USE FIDACY

If your agents never act across a trust boundary, they only touch systems you fully control, and no external party ever has to accept your word, you may not need Fidacy yet. The day an outside party has to trust what your agent did, you will.