Prefer signatures over transactions when possible. Signatures are gasless, don’t require network switching, and work seamlessly with Privy embedded wallets.
┌─────────────────────────────────────────────────────────────────────┐│ 1. User: "Buy 0.1 ETH at $3000 on Hyperliquid" │└─────────────────────────────────────────────────────────────────────┘ ↓┌─────────────────────────────────────────────────────────────────────┐│ 2. AI Agent calls your place_order tool │└─────────────────────────────────────────────────────────────────────┘ ↓┌─────────────────────────────────────────────────────────────────────┐│ 3. Your tool returns SignatureRequest in _meta.handshakeAction │└─────────────────────────────────────────────────────────────────────┘ ↓┌─────────────────────────────────────────────────────────────────────┐│ 4. Context Platform intercepts, shows approval card to user │└─────────────────────────────────────────────────────────────────────┘ ↓┌─────────────────────────────────────────────────────────────────────┐│ 5. User clicks "Sign" → wallet signs EIP-712 data (gasless!) │└─────────────────────────────────────────────────────────────────────┘ ↓┌─────────────────────────────────────────────────────────────────────┐│ 6. Signature returned to your callback tool for order submission │└─────────────────────────────────────────────────────────────────────┘
Gasless & Chain-Agnostic: EIP-712 signatures don’t require gas or network switching. The chainId in the domain is purely informational — signing works from any network.
Security: The authUrl domain must match your tool’s endpoint domain. Context appends the user’s DID as ?context_did=... for you to associate the auth with the user.
┌─────────────────────────────────────────────────────────────────────┐│ 1. User: "Post 'Hello!' to my Discord" │└─────────────────────────────────────────────────────────────────────┘ ↓┌─────────────────────────────────────────────────────────────────────┐│ 2. Tool checks: Does this user have Discord tokens? ││ → NO: Return auth_required handshake │└─────────────────────────────────────────────────────────────────────┘ ↓┌─────────────────────────────────────────────────────────────────────┐│ 3. Context shows "Connect to Discord" card ││ User clicks → Popup opens to your /auth/discord │└─────────────────────────────────────────────────────────────────────┘ ↓┌─────────────────────────────────────────────────────────────────────┐│ 4. User authorizes in Discord → Callback stores tokens ││ Popup sends postMessage → Context detects success │└─────────────────────────────────────────────────────────────────────┘ ↓┌─────────────────────────────────────────────────────────────────────┐│ 5. Tool is called again (auto-retry) ││ → YES, user has tokens: Post message to Discord │└─────────────────────────────────────────────────────────────────────┘
Token Security: Never expose user OAuth tokens. Store them encrypted on your backend, mapped to the user’s Context DID. Your tool receives the DID on every request, allowing you to look up the stored tokens.
Domain Requirement: Your authUrl must be on the same domain as your MCP endpoint. This prevents phishing attacks where a malicious tool redirects to a fake auth page.
Domain Validation: For auth_required, the authUrl domain must match your tool’s endpoint domain. This prevents phishing attacks where a malicious tool redirects users to fake auth pages.
No Private Keys: The user’s wallet signs the data client-side. Your tool never sees private keys — only the resulting signature.
The Context marketplace supports authentication flows that are generalizable — where solving the problem once enables infinite integrations.
Flow Type
Support
Rationale
EIP-712 Signatures
✅ Full
Universal standard. Hyperliquid, dYdX, and many DeFi protocols accept signatures directly. One implementation, infinite platforms.
OAuth 2.0
✅ Full
Industry standard. Discord, Twitter, and thousands of services use OAuth. Standardized token exchange.
API Key Auth
❌ Redirect
Platform-specific. Each API has different auth schemes, key derivation, HMAC formats, and storage requirements. Not scalable.
Why no API key support? Platforms like Polymarket require API keys derived from wallet signatures on their site, with custom HMAC authentication for every request. This cannot be delegated through the handshake architecture.If your tool requires API keys, you have two options:
Provide read-only features with a redirect link for write actions
Accept user-provided keys as input parameters (user manages their own credentials)
Want API key support? We’re monitoring demand. If you’re building a tool that needs this pattern, open an issue describing your use case.