Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.sigilcore.com/llms.txt

Use this file to discover all available pages before exploring further.

​
Getting Started

Sigil Sign is the deterministic execution firewall for agent-driven EVM actions. It sits between your AI agent and the blockchain, ensuring that high-stakes actions cannot execute without explicit authorization. Base URL: https://sign.sigilcore.com

​
API Quick Start

The fastest path to your first governed action. The Sigil API handles signing infrastructure, key management, and attestation issuance so you do not have to run anything yourself. 1. Get your API key. Register your email at sigilcore.com/tools/keys to receive a Developer tier key. 1,000 governed actions per month, free. 2. Sign your warranty.md. Use Sigil Warrant to define your policy and generate a signed warranty.md. The tool produces your Ed25519 keypair in the browser, signs the policy, and gives you your SIGIL_OPERATOR_PUBLIC_KEY value. 3. Authorize your first action. Submit an intent to POST /v1/authorize with your API key. If the intent passes your policy, you receive an Ed25519-signed JWT. Attach it to your transaction via Authorization: Bearer <jwt> and route through the Sigil RPC gateway. That is the complete flow. The sections below cover each step in detail. Pricing tiers:
TierCostGoverned actions
DeveloperFree1,000/month
Growth$25/month10,000/month, $0.002 per action above
EnterpriseCustomDedicated infrastructure, custom SLAs, audit support via Sigil Governance
Need to run your own signing infrastructure? sigil-sign is MIT-licensed and self-hostable. See the Self-hosted deployment section below. For most teams, managing your own cryptographic signing layer is unnecessary overhead.

​
Before You Deploy: Two Prerequisites

Whether you use the hosted Sigil API or self-host sigil-sign, two things must be in place. Without both, the service refuses to authorize anything. This is intentional — the service will not run without a verified operator policy.

​
1. A signed warranty.md file

Your warranty.md defines what your agent is allowed to do. The file must be signed with your Ed25519 operator key. An unsigned policy file is rejected at startup. Use Sigil Warrant to generate, sign, and download your warranty.md. Two paths are available:
  • Warrant Builder — guided step-by-step flow covering all four policy blocks. No policy syntax required. Recommended for first-time operators.
  • Manual Warrant — write your policy directly in the warranty.md format. Full control over every field.
Both paths generate your Ed25519 keypair in the browser (no key material ever leaves your machine), sign the policy, and provide your SIGIL_OPERATOR_PUBLIC_KEY value ready to paste. Deploy the signed warranty.md to your server and set WARRANTY_PATH to its location. If you omit this path, the service looks for config/warranty.md relative to process.cwd().

​
2. SIGIL_OPERATOR_PUBLIC_KEY environment variable

Set this to the base64url-encoded public key value Sigil Warrant gives you in Step 1. Sigil Sign verifies your policy signature against this key at startup. 
SIGIL_OPERATOR_PUBLIC_KEY=<base64url-encoded-public-key>
This variable must be present in .env.local (development) or your production environment. If it is missing, the service throws with: 
[Sigil] SIGIL_OPERATOR_PUBLIC_KEY is not set.
Together, these two items form the cryptographic chain: operator signature → policy content → Intent Attestation JWT Every attestation your service issues is verifiably linked to the exact policy version you signed and deployed. If anyone modifies the warranty.md after signing, Sigil Sign detects it on the next restart and refuses to start.
Sigil Warrant is the tool that satisfies both requirements. It lives at sigilcore.com/tools/warrant. Use the guided Builder or Manual flow to generate your keypair, define your policy, and download the signed file. The whole flow takes under two minutes.

​
The Execution Flow

Once your policy is deployed, executing an agent-driven transaction is a strict two-step process:
  1. Request Authorization: Submit your intent to the firewall to receive a short-lived Intent Attestation.
  2. Execute: Submit the transaction to the Sigil RPC/Bundler gateway, attaching the attestation as your authorization bearer token.

​
Step 1: Request an Intent Attestation

Before your agent can route a write transaction, it must obtain an Intent Attestation. Endpoint: POST /v1/authorize 
curl -X POST https://sign.sigilcore.com/v1/authorize \
 -H "Content-Type: application/json" \
 -d '{
   "framework": "agentkit",
   "txCommit": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
   "agentId": "agent_alpha_01",
   "chainId": 8453,
   "intent": {
     "action": "wallet.transfer",
     "targetAddress": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
     "amount": "1000000000000"
   }
 }'
Crucial Formatting Rules:
  • framework: A string identifying your agent framework (e.g. "agentkit", "eliza", "langchain"). Any non-empty string is accepted. See the Framework Registry for known values.
  • txCommit: Must be a lowercase 64-character hex SHA-256 string. Do not include a 0x prefix.
  • chainId: Must be in your warranty.md allowed_chains list. Supported values: 1, 10, 56, 137, 999, 8453, 42161.
  • intent.action: Must be in your warranty.md allowed_actions list (or the per-chain override for the requested chain).
If your intent passes your warranty.md policy, you will receive an Ed25519-signed JWT in the intent_attestation field. The JWT embeds a policyHash — a SHA-256 of the exact policy content that was evaluated, excluding the signature block. This is your cryptographic proof that the correct policy version was in effect.

​
Step 2: Route the Transaction

Once you hold a valid Intent Attestation, you have exactly 60 seconds to execute the transaction. Read operations are public. Write operations require your Intent Attestation. Endpoints:
  • Standard EVM: POST /rpc/:chainId
  • Account Abstraction: POST /bundler/:chainId
Provide your attestation in the headers using either Authorization: Bearer <jwt> or Sigil-Receipt: <jwt>. 
curl -X POST https://sign.sigilcore.com/rpc/8453 \
 -H "Content-Type: application/json" \
 -H "Authorization: Bearer eyJhbGciOiJFZERTQSIsInR5cCI6IkpXVCJ9..." \
 -d '{
   "jsonrpc": "2.0",
   "method": "eth_sendRawTransaction",
   "params": ["0x..."],
   "id": 1
 }'

​
Verifying Attestations Locally

You do not need to trust the firewall blindly. You can verify Intent Attestations locally using Sigil’s published JWK set. Endpoint: GET /.well-known/jwks.json Verification rules are strictly defined in our canonical specification: sigil-attestations.

​
Defining Your Policy

Your warranty.md uses typed section blocks. Sigil Sign evaluates them at runtime to govern agent behavior. Use Sigil Warrant to generate a signed policy interactively. The tool produces a signed warranty.md with an embedded Ed25519 operator signature — the cryptographic proof that the policy evaluated at runtime is the one you authorized. Pre-built templates for common deployment contexts are available in the FAF policy-templates directory.

​
Policy Format Reference

Sigil Sign parses a strict structured Markdown format. At least one of ## evm, ## tool_calls, or ## custom is required. Unknown fields are rejected at parse time. The ## signature block at the end is generated by Sigil Warrant — do not edit it manually. 
version: 1.0.0

## evm
max_transaction_eth: 5.0
allowed_actions: wallet.transfer, contract.call
allowed_chains: 1, 8453, 42161
chain_actions:
  "1": wallet.transfer, contract.call
  "8453": wallet.transfer
consensus_threshold_eth: 3.0
consensus_require_hold: true

## tool_calls
allowed: bash, web_fetch, file_write, wallet_sign, email.send
bash.blocked_commands: rm -rf, curl, wget
web_fetch.blocked_domains: evil.com, malicious.io
file_write.blocked_paths: /etc, /root, ~/.ssh
email.require_approval: true

## custom
deny_if.metadata.phone starts_with +1900
deny_string: DROP TABLE

## soft_limits
daily_evm_limit_eth: 20.0
daily_tool_calls: 500

## signature
sigil-sig: <base64url-ed25519-signature>
SectionBehavior
## evmEVM transaction limits and consensus gates. Violations return DENIED. Consensus-gated intents return PENDING.
## tool_callsAgent tool call allowlist and blocklists. Blocked calls return DENIED.
## customOperator-defined deny rules. Matches return DENIED.
## soft_limitsAggregate daily caps. Evaluation-only — never a hard denial.

​
Updating Your Policy

If you update your warranty.md, you must re-sign it with Sigil Warrant before redeploying. An updated but unsigned policy will be rejected at startup. The version field in your policy should be incremented to reflect the change — this makes the new policyHash in subsequent attestations distinguishable from the previous version.

​
Self-hosted Deployment

sigil-sign is MIT-licensed and can be run on your own infrastructure. This path gives you full control over the execution firewall, policy storage, and signing keys. For most teams, the hosted Sigil API is the faster and lower-maintenance option. The minimum deployment surface: 
sigil-sign/
  ├── config/
  │   └── warranty.md   # signed operator policy
  └── .env.local         # SIGIL_OPERATOR_PUBLIC_KEY
Set SIGIL_OPERATOR_PUBLIC_KEY in .env.local and place your signed warranty.md at the path WARRANTY_PATH points to (defaults to config/warranty.md). The prerequisites and execution flow documented above apply identically to self-hosted deployments.