Skip to main content

​
Errors & Policy Violations

A SIGIL_POLICY_VIOLATION means your proposed transaction was successfully processed, but it deterministically breached a rule in your ASSURANCE.md policy. This is not a bug; it is the firewall working as intended.To diagnose:
  1. Read the message or reason field in the JSON-RPC error response.
  2. Open your ASSURANCE.md and locate the breached constraint.
  3. Verify your request’s amount, targetAddress, and chainId match the policy.
Do not retry the exact same transaction. If the evaluation is deterministic, it will fail again. Fix the intent or the policy first.
SIGIL_VALIDATION_* errors mean your request failed schema validation before policy evaluation even began.Common culprits:
  • framework: Must be exactly "agentkit" or "eliza". "coinbase-agentkit" will fail.
  • txCommit: Must be a lowercase 64-character hex string. Remove the 0x prefix.
  • chainId: Ensure you are targeting an allowlisted chain (1, 8453, 42161, 10, 137, 56, 999).
Policy and validation failures on the /rpc and /bundler endpoints are returned as standard HTTP 200 JSON-RPC errors.Example:
{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32602,
    "message": "SIGIL_POLICY_VIOLATION",
    "data": {
      "reason": "Sigil receipt required for write methods"
    }
  }
}

​
Attestation Verification

Attestations expire exactly 60 seconds from issuance. This strict window prevents replay attacks.
  1. Discard the expired token. It will be rejected.
  2. Request a new attestation by calling POST /v1/authorize again.
  3. Ensure your agent is not performing blocking operations (like heavy LLM reasoning) between receiving the attestation and submitting the transaction.
No. Attestations are single-use. They are cryptographically bound to a specific txCommit or userOpHash. Submitting an attestation with a different transaction hash will instantly fail validation.
Intent Attestations are standard Ed25519-signed JWTs. You can verify them using the jose library and Sigil’s public JWK endpoint.
import { createRemoteJWKSet, jwtVerify } from "jose";

const JWKS = createRemoteJWKSet(
  new URL("https://sign.sigilcore.com/.well-known/jwks.json")
);

const { payload } = await jwtVerify(intent_attestation, JWKS, {
  issuer: "sigil-core",
  algorithms: ["EdDSA"],
});

// CRITICAL: Ensure payload.txCommit matches your transaction hash
console.log(payload);

​
Key Custody & Security

Never. Sigil is explicitly non-custodial.We do not hold your private keys, custody your treasury assets, or issue long-lived credentials to your agents. Sigil operates strictly as an authorization firewall. The agent proposes, Sigil authorizes, and your own key infrastructure (e.g., Fireblocks, AWS KMS) physically signs the transaction.