Advanced

FFP — Furge Fabric Protocol

Decentralised consensus for critical operations. When enabled, financial API calls require network approval before they execute.

What is FFP?

FFP is an optional security layer that sits between your agents and high-stakes external services (payment processors, exchanges, etc.). When an agent tries to call a protected domain, FFP submits a consensus proposal to the network. The operation only proceeds if the network approves it within 30 seconds.

This is useful when you want a second layer of verification beyond standard authentication — for example, in automated trading bots, multi-agent financial workflows, or anywhere you cannot afford a rogue or compromised agent to make real money moves unilaterally.

ℹ️
For most users, FFP is not needed. Standard bearer token auth is sufficient for the vast majority of use cases. Enable FFP only if you are running high-stakes multi-agent workflows involving financial APIs.

How it works

1
Agent makes a net_http_* call to a protected domain
e.g. net_http_post to https://api.binance.com/...
2
FFP intercepts the request
Before the HTTP request fires, the FFP client submits a consensus proposal to the configured FFP node.
3
Network votes
The FFP network evaluates the operation against its policy rules and registered agent reputation. Approval or denial comes back within 30 seconds.
4
Operation proceeds or is blocked
If approved: the original HTTP request fires normally. If denied or timed out: the operation is blocked and the agent receives an error.
5
All outcomes are logged
Every FFP operation — approved, denied, or timed out — is written to the FFP audit trail. Query it at GET /api/ffp/audit/:agentId.
Flow diagram
Agent → net_http_post(binance.com, ...)
↓
FFP client ffpConsensus() — submit proposal
↓ (30s timeout)
Approved → HTTP fires ✓Denied → blocked ✗
↓ always
ffpLog() — write to audit trail

Protected domains

When FFP_REQUIRE_CONSENSUS=true, the following domains require consensus approval before any HTTP call is allowed:

binance.comCrypto exchange
coinbase.comCrypto exchange
kraken.comCrypto exchange
stripe.comPayment processor
paypal.comPayment processor
braintreepayments.comPayment processor

All other domains pass through without any FFP overhead.

How to enable FFP

FFP is controlled entirely through environment variables. Set these in your deployment environment (Vercel, Docker, .env, etc.):

.env / environment variables
# Required to activate FFP
FFP_MODE=enabled

# The chain/network identifier for your FFP node
FFP_CHAIN_ID=mainnet

# URL of the FFP network node you are connecting to
FFP_NODE_URL=https://your-ffp-node.example.com

# This deployment's agent identity on the FFP network
FFP_AGENT_ID=agent_abc123...

# Set to true to actually block protected domains pending consensus
# Without this, FFP logs operations but doesn't block anything
FFP_REQUIRE_CONSENSUS=true
⚠️
If any of FFP_MODE, FFP_CHAIN_ID, FFP_NODE_URL, or FFP_AGENT_ID are missing, FFP is automatically disabled and all calls are no-ops — existing deployments are completely unaffected.

Enable in the Ops console:

  1. Set the environment variables above and redeploy.
  2. Go to /ops and switch to Multi-agent mode.
  3. The FFP / Consensus Mode button will become active. Click it to enable.
  4. The button now shows "Consensus On" — all protected domain calls will now require network approval.

FFP API endpoints (admin only)

GET/api/ffp/status

Returns current FFP configuration: whether it is enabled, the chain ID, node URL, and whether consensus is required.

Example response
{
  "enabled":          true,
  "chainId":          "mainnet",
  "nodeUrl":          "https://...",
  "requireConsensus": true
}
GET/api/ffp/audit/:agentId

Query all operations logged on the FFP chain for a given agent. Optional query params: chain_id, start_time, end_time.

Example response
[
  {
    "primitive":  "net",
    "action":     "http_post",
    "params":     { "url": "https://api.binance.com/..." },
    "result":     { "approved": true },
    "timestamp":  1743500000,
    "agentId":    "agent_abc123..."
  }
]
GET/api/ffp/consensus/:agentId

Query the consensus proposal history for an agent — which proposals were submitted, approved, denied, or timed out.

Example response
[
  {
    "proposalId": "prop_xyz...",
    "domain":     "binance.com",
    "status":     "approved",
    "createdAt":  "2026-03-31T..."
  }
]

Check FFP status via curl:

curl -s https://agentos-app.vercel.app/api/ffp/status \
  -H "Authorization: Bearer $ADMIN_TOKEN" | jq

Zero-overhead when disabled

When FFP is not configured, every call to ffpLog() and ffpConsensus() is a synchronous no-op — it returns immediately without any network call or side effect.

This means you can deploy AgentOS without FFP and it will never slow down a single request. FFP only adds latency (the consensus round trip) when it is explicitly enabled AND the target domain is in the protected list.

Open Ops Console →Back to full guide