Influence over a decision, without control of the transaction.

Fidren cannot:

• hold funds
• hold private keys
• have signing authority
• execute payments
• settle transactions
• replace your wallet or payment infrastructure
• present as a wallet, a payment processor or an x402 facilitator

Stated as capability rather than as policy, because a security reader is asking what is possible, not what is intended. ALLOW_WITH_ESCROW means use an escrow, never use ours: Fidren recommends the condition, and an escrow you choose and control enforces it.

A test sweeps the routes the server serves and the paths the API contract declares, and fails if a custody, transfer or signing operation appears. That is a regression guard against future drift, not a proof that no such capability could ever be added.

Authentication, validation and limits.

Authentication is explicit, per route

Each protected route attaches its own guard rather than relying on a global hook with an exemption list, so the requirement is visible where the route is declared. Every route is also classified as public or protected, and the build reconciles that classification against the server's own routing table and then calls each route without a credential to confirm the answer matches its class. A new route nobody classified, or a protected one that lost its guard, fails the build. This is a build-time gate rather than a runtime property, which is why the page does not use a stronger word for it.

Some surfaces are public by design

Reading an address profile, health and readiness, the API document, and the dispute channel. The last is the deliberate one — a party contesting a record is usually not a customer and holds no key, so requiring one would turn a right of reply into something sold to the people being assessed. Those routes are written for a hostile caller.

Keys are stored as a digest, never in the clear

The plaintext is generated server-side, shown once, and not written down; a leaked database yields no usable credential. Absent, malformed and unknown keys all return the same refusal, so error text cannot be used to enumerate valid ones. A revoked key stops working on the next request. Keys are never written to a log — not the key, not a prefix of it.

Input is validated before anything acts on it

Bodies and parameters are parsed against a schema at the route boundary; oversized bodies are refused before parsing. Responses are assembled field by field rather than serialised from engine objects, which is what keeps the internal scoring breakdown out of a reply.

Rate limits key on a credential Fidren issued

Not on the one in the request. A key the service does not recognise is not a credential and buys nothing; that caller falls back to a bucket keyed on their network address. Without that, inventing a fresh key per request would produce an empty budget at the higher allowance. The counter is per process, so a second replica would hold its own.

Not implemented

Named because a reader will look for them, and discovering their absence during integration is worse:

• key rotation as a workflow — revoke and create
• key expiry
• scopes or per-key permissions
• IP restrictions
• separate test and live keys
• self-service key creation
• a third-party audit, a certification or a compliance attestation
• a formal vulnerability disclosure programme

What a chain of reports proves.

Each side of an operation keeps its own chain. Every report commits to the digest of its predecessor and the server computes the links, so a reporter cannot reorder or edit its own account after the fact.

Recorded

An authenticated caller submits a report naming a side and an address. It is recorded and attributed to the API key. Two narrow guards apply: a side already reported by one address cannot be taken over by another, and one address cannot hold both sides of the same operation.

Signed

A report may carry a signature from the reporting address. Signing is optional; a signature is verified and stored only if it verifies, so a stored signature is a verified one and an invalid one is dropped rather than kept. Only a signature shows the reporter controls the address it names — an unsigned report rests on the API key alone.

Corroborated

Both sides reported, their accounts agree, and each signed its own. Only that combination counts as coverage. Separately signed reports may still come from parties under common control, so corroboration is not independent verification.

The endpoints and request shape behind each level are on Developers.

The public site, and what is written down.

Every page renders on the server. Fidren's public application ships no application JavaScript of its own, which reduces the application-side client scripting attack surface, and output is escaped on the server on every interpolated value — including anything a visitor typed into a form and got back on an error page. A browser may still execute the security script the edge injects, so what the origin emits is not what a visitor runs.

The content security policy denies everything by default and names only what Fidren actually serves, with no 'unsafe-inline' in either the script or style directive — the views carry no inline styles precisely so the allowance can stay off. A per-response nonce is present not because Fidren renders inline script, but so the edge's injected security script can be stamped with it under a strict policy. The two are designed to compose under a real browser and the edge that fronts it; confirming that in practice belongs to this site's browser release checks. Framing is denied, transport security is sent over HTTPS, and features an institutional site has no business requesting are turned off.

Indexing is decided per route: the institutional pages are indexable, and the address lookup is not — it carries the directive in both the document and the response header, and no listing makes addresses discoverable in bulk. It is deliberately not blocked in robots.txt, because a crawler that is blocked never fetches the page and so never reads the directive.

Credentials are redacted by the logger rather than remembered at each call site: the Decision API replaces authorization and API-key headers and cookies before a line is written, and this site, which issues no key and sets no cookie of its own, redacts the same credential headers a visitor could still send it. Contact and design-partner message bodies are not logged; a delivery failure records operational metadata and none of what the visitor wrote.

The two public forms share one submission path. Fields are validated on the server whatever the browser did, values that return on an error page are escaped, there are anti-spam measures, submissions are rate limited per sender and in aggregate, and a submission token is single-use so an accidental double click is refused while a deliberate retry is not. Delivery fails closed: a failed send is reported as failed and never as received, queued or saved, and with no real transport configured — or before the privacy review and the named data controller are settled — the form does not accept submissions at all rather than accepting them into nothing.