Docs
PATH CONNECT
Bounded, revocable authorisation — for delegated applications, recurring mandates and agents acting on someone's behalf.
LIVE largely — connection objects and scopes are implemented; exposed counters and delegation binding are DRAFT.
The problem it solves
Granting an application permission to move money is usually all or nothing. The application asks for access, the user says yes, and from then on nobody — including the user — can answer three basic questions:
- What exactly is it allowed to do?
- How much of that has it already used?
- How do I stop it, right now, without closing the account?
PATH CONNECT makes the grant an object with a scope, a counter and a revocation.
The connection
{
"id": "conn_8d31",
"grantee": "member-b",
"grantor": "member-a",
"subject": "sub_9f2c41a8",
"capabilities": {
"payment_request": true,
"view_balance": false
},
"policy": {
"max_single": "100000",
"max_total": "500000",
"currency": "XOF",
"expires_at": "2027-01-01T00:00:00Z"
},
"status": "active",
"kid": "op_example_2026_01",
"signature": "…"
}Directional: this party is authorised against that account, for these capabilities, within these limits. Not "connected", which says nothing about direction or extent.
Two modes
| Mode | Each operation | Suits |
|---|---|---|
per_operation_signature | Signed individually by the subject | High value, low frequency |
persistent_consent | Covered by the standing grant, within limits | Low value, high frequency |
persistent_consent is where the limits earn their place. Without a ceiling and a counter it is
just an unbounded grant with better paperwork.
Delegation
DRAFTA delegation token authorises a third party — an application, an agent — to act within a subset of a connection.
Two properties are non-negotiable.
It is bound to the operation
{
"binds_to": {
"operation_type": "payment_request",
"amount": "5000",
"currency": "XOF",
"destination_commitment": "8f29…"
}
}A token that authorises "a payment" authorises every payment. Binding it to the amount and to a commitment over the destination means an intercepted token cannot be redirected or resized. Without the binding, a token stolen in transit is a blank cheque with an expiry date.
Its counters are visible
{
"limits": { "max_total": "500000", "currency": "XOF" },
"consumed": { "total": "125000", "operations": 7 },
"remaining": { "total": "375000" }
}A limit nobody can read is a limit nobody can plan against. The holder of a token should be able to see what remains without attempting an operation and being refused — and a user reviewing their grants should see the same numbers.
Mandates
A recurring mandate is a connection with a schedule. This is where subscribe links land, and the
reason they belong here rather than in PATH REQUEST:
A payment request is a claim — one amount, one deadline, gone once paid. A mandate is a permission — it persists, it recurs, and it must be revocable.
Treat a subscription as a payment request and you ship without revocation and without counters, and discover it when a customer asks how to cancel.
The mandate digest — the canonical form of the terms a subject consented to — is computed over canonical JSON. Anything else and two implementations produce different digests for identical terms, which makes the consent unverifiable across a boundary.
Revocation
Immediate, unilateral, and available to the subject at any time.
Three things a specification should require and implementations often miss:
It takes effect at execution, not at issuance. A token issued this morning and revoked since must fail now. Any cached authorisation status is a hole.
It is broadcast. A revoked delegation must stop being honoured across the network, not only at the operator that revoked it.
It leaves the record intact. Revocation ends the permission; it does not erase what was done under it. A dispute needs the history.
Financial connection requests
A connection request that asks for financial capability follows the same object with an explicit consent step, and one rule about ordering that is easy to get backwards:
Match before consent. The subject is shown who is asking and what for before being asked to approve — and a request that does not match a known counterparty never reaches a consent screen at all. A consent screen shown for an unresolved counterparty trains people to approve things they cannot evaluate, which is the mechanism behind most authorised-push-payment fraud.