Integrations

IGNITRA works with other Robinhood Chain services: VIGIL alerts start flows, TRUST LAYER scores become conditions, MANDATE policies approve onchain actions, and Pons launches are a trigger.

VIGIL → the VIGIL alert trigger

VIGIL watches contracts and raises alerts (upgrades, ownership and role changes, pauses…). A flow can run on them.

1. Add a VIGIL connection in Connections. With a VIGIL API key (vgl_…), IGNITRA registers its receiver in your VIGIL account itself: the key is used once and not stored. Without a key, you get a receiver URL: add it as a webhook in VIGIL, then paste the signing secret VIGIL shows. Alerts are refused until then.
2. Pick the VIGIL alert trigger: confirmed alerts (default) or new ones before confirmation, a minimum severity, and optionally only some rules or contracts.

• IGNITRA checks every delivery's x-vigil-signature (HMAC-SHA256 over "<timestamp>.<raw body>") and refuses anything older than 5 minutes.
• An alert runs a flow once per stage, however often VIGIL retries the delivery. A retracted alert runs only flows that ask for it.
• The trigger data has the alert (rule, severity, title, summary, contract, actor, before / after, VIGIL's evidence) and counterparty = the actor, for TRUST LAYER scores.

TRUST LAYER → trust conditions

TRUST LAYER scores Robinhood Chain addresses from 0 to 1000 (higher is more trustworthy). Flows can filter on the score of a party of the event, e.g. only buys by addresses scoring under 300:

{
  "all": [
    { "field": "percent_of_supply", "op": ">=", "value": 0.5 },
    { "field": "counterparty_trust_status", "op": "==", "value": "scored" },
    { "field": "counterparty_trust_score", "op": "<", "value": 300 }
  ]
}

• A score is never invented. When there is no real score, *_trust_score is null and *_trust_status says why: pending (TRUST LAYER is still indexing the address), insufficient_data, not_a_subject (a system address), unavailable (not reachable), skipped (the other conditions failed, so it was not looked up) or not_applicable (no such party, e.g. no counterparty without a watched wallet). scored and provisional come with a number.
• A condition on a null score is false, so a flow that requires a high score does not run when the score is missing. Add a status condition when “unknown” should behave differently.
• Scores are fetched only for flows that use them, after the other conditions pass, and cached briefly per address.

MANDATE → policies for onchain actions

MANDATE is a policy service that must approve every onchain action of the grants that name it. The server operator can require one for every grant. Add it in Connections with its endpoint URL: you get a signing secret once, to verify that requests come from IGNITRA.

The request

Before signing a transaction, IGNITRA POSTs the exact call it would make, signed like its webhooks with the connection's own secret:

POST <your policy endpoint>
Content-Type: application/json
X-Ignitra-Signature: v1=<hex HMAC-SHA256(secret, "<timestamp>.<raw body>")>
X-Ignitra-Timestamp: 1794060000
X-Ignitra-Idempotency-Key: 4663:0x…:12:fl_…:pay
X-Ignitra-Event: onchain.intent

{
  "type": "onchain.intent",
  "intent_id": "5b1c…",
  "chain_id": 4663,
  "grant_id": "grt_…",
  "safe": "0x…",
  "session_key": "0x…",
  "to": "0x5fc5360d0400a0fd4f2af552add042d716f1d168",
  "function": "transfer(address,uint256)",
  "selector": "0xa9059cbb",
  "args": ["0x…", "1000000"],
  "value_wei": "0",
  "flow_id": "fl_…",
  "run_id": "run_…",
  "step_id": "pay",
  "idempotency_key": "4663:0x…:12:fl_…:pay",
  "test": false,
  "sent_at": "2026-11-08T02:00:00.000Z"
}

The answer

200 { "decision": "allow", "policy_id": "pol_7" }
200 { "decision": "deny", "reason": "counterparty frozen", "policy_id": "pol_7" }

• Fail-closed: only "decision": "allow" lets the transaction through.
• deny is final: nothing is sent, the step fails with your reason and is not retried. The decision is logged with the action.
• Anything else (no answer within 5 seconds, a non-200 status, malformed JSON, another decision): nothing is sent, and the step is retried later.
• A retried step carries the same idempotency_key; intent_id is new for every request. TEST runs only simulate and do not ask MANDATE.

Pons → the Pons launch trigger

The Pons launch trigger runs when a token launches on Pons (the V2 launch factory's TokenLaunched event), optionally only for one deployer. The data has the token (symbol, decimals, supply), the deployer, the bonding curve, what it trades against (ETH or a token) and its graduation threshold.

socials.* are links the launcher typed: unverified. Do not treat them as proof of anything. Combine with counterparty_trust_score (the deployer) to filter launches.