Know how much to risk before your agent pays.
Ask Fidren about a counterparty before you send money. You get an assessment of who they are, the exposure the record supports, what to do about the amount you asked for, and the evidence behind all three.
100 free decisions per day, per IP. No account · No card · No wallet
Fidren Decision Layer
- 01 Evidence
- 02 Signal
- 03 Confidence
- 04 Limit
- 05 Decision
Your agent acts
Fidren returns the decision. Your infrastructure executes the payment — or does not.
Autonomous systems move money faster than anyone can check who they are paying.
An agent that can pay is an agent that can pay the wrong party, at machine speed. Review after the fact is not review.
So before it pays, something has to be able to ask:
- What has actually been observed about this counterparty?
- What do the parties who dealt with them report?
- How much of the record is that answer resting on?
- How much exposure is reasonable here?
- Should this specific transaction proceed?
Fidren exists to answer those five questions in one call, and to keep the answer explainable afterwards.
Five stages produce an answer. The sixth is what happens after it.
Evidence becomes a decision, and the outcome comes back.
The last stage feeds the first: outcomes reported after a payment become evidence for the next question about that counterparty.
-
01
Evidence
Settlement behaviour observed on chain, plus the outcomes each side reported afterwards.
-
02
Signal
The adverse and informational findings the evidence supports. Each one is a named signal, not an impression.
-
03
Confidence
How much of the record the answer rests on. A thin record produces a hedged answer, not a confident guess.
-
04
Limit
The per-transaction ceiling the record supports for this counterparty, weighed against the exposure you asked for.
-
05
Decision
One of five actions, returned with that ceiling and the reasons behind it. Your agent honours the action; Fidren never acts on it.
-
06
Record
What each side reports afterwards, appended to a chain the server computes, so the next question about this counterparty meets a fuller record.
No decision call performs stage 06 — it runs only when, and if, a party later reports how an operation went.
Five actions, not a score to interpret.
Every answer comes back with the recommended limit, confidence and reasons behind it. What each action means is on Product.
Three related concepts. Collapsing them is how an answer gets misread.
Risk, confidence and exposure are not the same thing.
- Counterparty risk
- What the record says about the party being paid.
- Confidence
- How much record there is to say it from.
- Requested exposure
- The amount you are asking to put at stake.
How the three interact — including the pairs that surprise people — is the full breakdown on Product.
Unknown does not mean unsafe.
A counterparty Fidren has never observed is a counterparty Fidren has nothing to say about — a statement about the record, not about them. Treating absence of evidence as evidence of bad behaviour would make Fidren a gate that honest newcomers cannot pass.
So Fidren never blocks a counterparty for having no history. A thin record routes to a person instead, and the confidence that says why arrives as its own field rather than being rounded into the decision.
This is a boundary, not a current limitation. It does not move later.
Fidren never touches the money.
Fidren does not:
- hold funds
- hold your private keys
- have signing authority
- execute or settle payments
- replace your wallet
- replace your payment infrastructure
It sits beside the payment path and answers a question before the payment happens. Where an action recommends escrow, the escrow is one you choose and control — Fidren states the condition and never holds the funds that satisfy it. The trust boundary, the API-key model and what a security buyer should know before integrating are on Security.
Evaluate first. Depend on it second.
Run Fidren beside what you do today.
Shadow Mode is how you integrate, not a mode Fidren runs: the same decision comes back every time, and only your own code decides whether it gates the payment yet. There is no shadow flag, no dry-run parameter and no second decision engine.
The full model — what stays identical, what changes, and the path from observing to enforcing — is on Shadow Mode.
One call, before the payment. No credential needed.
One call your agent makes before it pays.
# request POST /v1/decision Authorization: Bearer <your-api-key> Content-Type: application/json { "address": "0x0000000000000000000000000000000000000001", "chain": "base", "amount_cents": 25000, "currency": "USDC" }
The fields, not a sample assessment. Fidren does not publish invented figures, including in documentation.
The full response and integration contract are on Developers. Enterprise keys are provisioned per partner; the free tier needs none.
An answer you can audit, on a surface built for clarity.
- Non-custodial
- Fidren cannot lose your funds to a custody compromise, because it never holds them.
- Explainable decisions
- Every action returns with its reasons and the evidence behind them.
- Authenticated API
- Authenticated calls, validated input, and a clear trust boundary.
Each of these is explained in full — the trust boundary, the API-key model, what is redacted from logs, and the limitations worth knowing before you integrate — on Security.
Fidren is early and is looking for design partners. Commercial pricing is not published yet.
Build with Fidren before autonomous payments scale.
The decisions worth getting right are the ones made before an agent has spent anything. If you are building systems that will pay counterparties without a human in the loop, we would like to hear what you are building.