A decision layer, before the payment.
Fidren sits beside your agent, one step before the money it is about to move. Your agent asks about a counterparty and an amount; Fidren answers from the record it holds; your own payment infrastructure acts on the answer, or does not. Fidren is never on the payment path.
This page is where that is explained in full: what Fidren receives, what it evaluates, what comes back, and where each of the five answers leaves you.
One question, asked before value moves.
Should this agent transact with this counterparty, on these terms, for this requested exposure?
Everything below is in service of answering that, and of making the answer accountable afterwards. Fidren does not tell you who a counterparty is — it has no identity product, performs no verification of identity, and does not attempt to link an address to a legal person. What it can tell you is what has been observed about the address you are about to pay, how much of a record that is, and what the record supports.
The full request and response are on Developers. These are the fields the request carries.
A counterparty, a chain, and how much you intend to pay.
Nothing about the person behind the address is asked for, because nothing about them is used. Not every chain named here is observed to the same depth today — the full coverage picture is on Developers.
Two kinds, held apart on purpose.
What Fidren has actually seen, and what it was told.
These are not the same thing and Fidren never presents them as though they were.
- Observed on chain
- Settlement Fidren watched happen: payments, their sizes, how long the address has been active, how many distinct counterparties it has dealt with. This half is direct — nobody had to tell Fidren about it. What it cannot show is whether anything was delivered in return. The chain proves a payment; it cannot prove the thing paid for arrived.
- Reported by the parties
- What each side says happened after a payment: delivered, failed, refunded, disputed. This half is attributed, never established. Fidren records that a party said something; it does not record that the thing is true, and no wording on this site will tell you otherwise.
An outcome only one side reports is recorded as evidence, but does not broaden the record — a party's own account costs one key to produce, so treating it as coverage would reward self-reporting. Corroboration needs both sides to report, sign, and agree; two unsigned reports that happen to agree are recorded but buy nothing, because they could be one reporter twice. A disagreement between two reports is itself a finding, recorded rather than adjudicated. None of this makes a corroborated record true: separately signed reports can still come from parties under common control. The full mechanics — Recorded, Signed, Corroborated, and that common-control limit — are on Security.
Evidence comes back with the decision as a list of named findings, each with a code, a plain-language detail and, where one applies, the observed value it was drawn from. Those are observations. The weights and bands that turn them into an answer are not published, here or anywhere.
Four terms. Collapsing any two of them is how an answer gets misread.
Counterparty risk, confidence, requested exposure and recommended limit.
- Counterparty risk
- What the available record indicates about the counterparty. It does not move when your request does, and it is not a prediction — it is what has been observed and what the observations support.
- Confidence
- How much of a record the answer rests on. LOW, MEDIUM or HIGH. Two questions, and the weaker answer wins: how much has been observed, and how much of the record those observations reach. An address with thousands of observed payments and nothing corroborated about whether it delivered has a great deal of data and a narrow record — and it is served at the narrow half.
- Requested exposure
- The amount you are asking to put at stake. Your input, not an assessment. It is why the same counterparty can draw one action for a small payment and another for a large one.
- Recommended limit
- The per-transaction ceiling the record supports. Fidren's output, returned with every decision — including the ones that tell you not to pay. It is a recommendation your infrastructure applies; Fidren enforces nothing.
They move independently — the pairs that surprise people are worth naming. A poor record backed by a great deal of evidence carries high risk at high confidence: the record is broad enough to say so. Almost nothing on file carries low apparent risk at low confidence, and that pair means little is known, not this is fine. Reading the second as the first is the mistake this section exists to prevent.
Fidren returns an action, not a number to interpret on your own. The internal scoring weights and thresholds are not public.
What each answer tells you to do.
- ALLOW
-
The record supports paying on the terms requested.
Nothing about the request needs to change. A ceiling still comes back, and it is not below what you asked for.
- ALLOW_WITH_LIMIT
-
The record supports paying up to the recommended limit.
The ceiling is the condition attached to this action — sometimes because the requested amount exceeds what the record supports, sometimes because the record sets one regardless of what was asked. Either way, it is what the record bears, and it moves when the record does.
- ALLOW_WITH_ESCROW
-
Paying is supported if settlement is held until delivery.
Support is conditional on settlement being held until delivery — Fidren states the condition, an escrow you choose and control satisfies it, and Fidren never holds the funds.
- REVIEW
-
The evidence does not settle the question.
A legitimate answer, not a failure — the one that asks for a person. Commonly where a thinly recorded counterparty lands, since Fidren never blocks anyone for having no history.
- BLOCK
-
The adverse findings outweigh what the record supports.
About this transaction, not a judgement about the counterparty. Fidren blocks nothing itself — the action is yours to honour.
Every one of the five comes back with a recommended ceiling, confidence, reasons and evidence — including BLOCK. Fidren performs none of these actions. It returns them, and your infrastructure honours them.
Five stages, in this order, on every call.
Evidence becomes a decision.
Nothing in the sequence is skipped. Where a dimension has no evidence behind it, that shows up in the confidence returned rather than in a guess. One call runs all five and returns the result.
-
01
Evidence
What Fidren holds about this counterparty: settlement observed on chain, and the outcomes each side reported.
-
02
Signal
The named findings that evidence supports. Adverse or informational, drawn from a fixed set, never free text.
-
03
Confidence
How much of the record the answer rests on. Reported with the decision rather than folded into it.
-
04
Limit
The per-transaction ceiling the record supports, which the requested exposure is then weighed against.
-
05
Decision
One of five actions, with that ceiling, the reasons and the evidence behind them.
-
06
Record
Afterwards, and only if a party reports: what each side says happened, appended to a chain the server computes. It becomes evidence for the next question about this counterparty.
Stage 06 is not part of answering a question. It happens later, if a party chooses to report — and it is optional, so a counterparty who never reports is not thereby suspect.
What each side reports afterwards becomes evidence.
Either end can report how an operation went. Each end keeps its own chain: the server appends that end's report to it and computes the links itself, so a reporter cannot reorder or edit its own account after the fact. Signing is supported and optional: an unsigned report is recorded as what it is, and a signature from the address that is reporting is what lets an agreeing account count as corroboration.
Those reports feed the next question about that counterparty. What they never become is a fact: the status that closes an operation as concluded records that a side considers it concluded and in order, not that Fidren checked. That distinction is deliberate and it is why nothing on this site describes an outcome as verified.
Evaluating Fidren without acting on the answer is Shadow Mode.
Two steps of five. The handover is the product.
Beside the payment path, never on it.
- Your agent or application is about to pay a counterparty Yours
- Fidren Decision API is asked about that counterparty and that amount Fidren
- A decision comes back: an action, a ceiling, confidence, reasons, evidence Fidren
- Your wallet and payment rails act on it, or do not. Fidren is not on this path Yours
- Your agent may report the outcome afterwards, which becomes evidence Yours
Money moves only in the step Fidren is not in.
A boundary, not a current limitation.
Fidren does not:
- hold funds
- hold your private keys
- have signing authority
- execute or settle payments
- replace your wallet
- replace your payment infrastructure
The security model, the operational posture and what this boundary means in practice are on Security, which owns them in full.
Fidren is early and is looking for design partners. Commercial pricing is not published yet.
Try it against something real.
The useful conversation starts with a system that is about to pay someone. If you have one, we would like to hear about it.