0x00000000000000000000000000000000000000990xbdc8a59Ec92065848D0a6591F1a67Ce09D5E5FA7HOST Primer
Smart contracts that speak HTTP. The first protocol-level outbound trigger in any EVM chain. Webhooks for Web3.
Try HOST Demos →The Silent Problem
Web3 has been a one-way street. Transactions bring data in from Web2. Smart contracts execute. But nothing goes back out. The silence is deafening.
Web2 runs on webhooks—Stripe, Shopify, Slack, GitHub. All Web3 offers is unreliable event logs. Web2 apps have to index, poll, and react asynchronously. Result: low developer adoption.
The Voice
HOST gives smart contracts a voice. The first protocol-level outbound trigger in any EVM chain. Contract sends data to your webhook during transaction execution. Signed by the validator. Provably authentic.
Web2 → Web3 → Web2. Complete. Your app calls a contract, the contract speaks back, your app responds instantly. No indexers. No polling. No middleware.
The Chain of Trust
HOST implements a strict security model to ensure that off-chain resources are accessed securely and only by authorized smart contracts. This prevents spam and ensures that Validator Nodes only expend resources on legitimate, approved requests.
The security model consists of three distinct layers of authorization:
The Node
The Validator who operates the physical infrastructure. Validators register their nodes on-chain to signal availability for processing HOST requests. Each node is identified by its unique address and linked to an owner address that manages approvals.
The Developer
An authenticated User (EOA) vetted by the Validator. Developers must request and receive approval from a Validator before they can use that node's services. This creates accountability and prevents anonymous abuse of validator resources.
The Application
A specific Smart Contract whitelisted by the Developer. Only contracts explicitly registered by an approved Developer can create HOST requests. This ensures fine-grained control over which code can trigger outbound HTTP calls.
Trust Flow
Workflow Lifecycle
Validator Onboarding
A Validator Node signals its availability to process HOST requests by callingregisterValidator(owner) on the Registry.
Mechanism
The Validator signs this transaction with their node key, proving ownership of the infrastructure that will execute HOST requests.
Result
The Registry maps the Node Address to an Owner Address (the administrative EOA capable of approving users).
Developer Access Request
A Developer who wishes to utilize a specific Validator's node must request permission on-chain.
Action
The User calls requestAccess(validatorNodeAddress)to formally request permission to use that validator's services.
Approval
The Validator's Owner Address monitors these requests and submits an approval transaction to whitelist the User's address.
Contract Whitelisting
Once approved, the Developer can explicitly authorize their smart contracts to use the system.
Action
The User calls registerContract(validatorNodeAddress, contractAddress)to whitelist their contract.
Result
The Registry now recognizes that contractAddress is managed by a trusted User and allowed to create requests for that Validator.
Request Execution
The authorized Smart Contract executes the request in a two-step atomic process:
Step A: Registration
The contract calls the HostRegistry function:
addRequest( url, // Target endpoint payload, // JSON body headers, // HTTP headers nodes // Validator addresses ) → requestID
- Validation: The Registry checks the Chain of Trust—Is this contract registered by a User? Is that User approved by the target Validator?
- Output: If valid, returns a unique
uint256 requestID.
Step B: Execution
The contract immediately invokes the HOST Precompile via static call:
(HOST_PRECOMPILE).staticcall( requestID )
- Action: The Validator node detects the call, verifies the ID against the Registry.
- Outcome: Performs the secure HTTP/S request off-chain to the specified endpoint.
HOST Protocol Encryption
HOST allows smart contracts to trigger HTTP webhooks with encrypted sensitive data (API keys, tokens, secrets). The encryption ensures that only the designated validator can decrypt the values when executing the webhook.
Encryption Scheme
- Algorithm: ECDH key agreement + AES-256-GCM symmetric encryption
- Curve: secp256k1 (same as Ethereum)
- Prefix: Encrypted values start with
|
Security Properties
- Asymmetric: Only the validator with the private key can decrypt
- Forward Secrecy: Each encryption uses a fresh ephemeral keypair
- Authenticated: GCM tag prevents tampering
- On-chain Privacy: Encrypted values appear as opaque hex blobs
Ciphertext Format
| + [ephemeralPubKey (65 bytes)] + [nonce (12 bytes)] + [ciphertext (variable)] + [authTag (16 bytes)] | - Magic prefix indicating encrypted value ephemeralPubKey - Uncompressed secp256k1 public key (0x04 prefix + 64 bytes) nonce - Random 12-byte IV for AES-GCM ciphertext - Encrypted data authTag - 16-byte GCM authentication tag
Client-Side Encryption (JavaScript)
const secp256k1 = require('secp256k1'); // v4.0.3 - CRITICAL: Must use v4.x
const crypto = require('crypto');
function encrypt(validatorPubkeyHex, plaintext) {
const validatorPubkey = Buffer.from(validatorPubkeyHex, 'hex');
// 1. Generate ephemeral keypair
let ephemeralPriv;
do {
ephemeralPriv = crypto.randomBytes(32);
} while (!secp256k1.privateKeyVerify(ephemeralPriv));
const ephemeralPub = Buffer.from(secp256k1.publicKeyCreate(ephemeralPriv, false));
// 2. ECDH - derive shared secret (raw x-coordinate)
const shared = Buffer.from(
secp256k1.ecdh(validatorPubkey, ephemeralPriv, { hashfn: (x, y) => x }, Buffer.alloc(32))
);
// 3. AES-256-GCM encrypt
const nonce = crypto.randomBytes(12);
const cipher = crypto.createCipheriv('aes-256-gcm', shared, nonce);
const encrypted = Buffer.concat([cipher.update(plaintext, 'utf8'), cipher.final()]);
const tag = cipher.getAuthTag();
// 4. Output format: | + hex(ephemeralPub || nonce || ciphertext || tag)
return '|' + Buffer.concat([ephemeralPub, nonce, encrypted, tag]).toString('hex');
}Usage in Smart Contracts
// Plaintext values - no encryption
string[] memory headerValues = new string[](2);
headerValues[0] = "application/json";
// Encrypted value - prefix with |
headerValues[1] = "|04abc123...def456"; // Encrypted API key
registry.addRequest(
"https://api.example.com/webhook",
'{"Content-Type":"$1","Authorization":"Bearer $2"}',
headerValues,
...
);Use Cases
Autonomous Agents
Smart contracts spawn AI agents that reason, plan, and execute multi-step tasks. Build self-governing DAOs, autonomous trading systems, and intelligent automation.
Agentic Workflows
Chain AI tools together—research, analyze, decide, execute. On-chain events trigger complex multi-step workflows that operate autonomously.
Event-Driven AI
On-chain events trigger AI analysis pipelines. Smart contracts invoke ML models to process data, generate predictions, and initiate downstream workflows.
Generative Content
NFT mints trigger AI image generation pipelines. Game actions spawn content creation workflows. On-chain events drive off-chain creative processes.
AI-Powered DeFi
DeFi events trigger AI analysis—liquidation predictions, yield optimization calculations, portfolio rebalancing signals sent to off-chain systems.
Intelligent Automation
On-chain events trigger AI decision pipelines. From supply chain notifications to customer service workflows—autonomous off-chain processes driven by blockchain state.
Host Registry App Coming Soon
A dedicated application for validators and developers to register nodes, request access, and whitelist contracts is currently under development.