EEP Monetization Guide
Gates (access control), commerce (price negotiation), and service listings (marketplace).
1. Gated Access
Gates let entities decide who gets access to what. You pick your own tier names and requirements.
Define Your Gate Config
{
"default_tier": "public",
"tiers": {
"public": {
"requirements": [],
"access": ["profile.summary", "profile.capabilities"]
},
"verified_agents": {
"label": "Verified Agents",
"requirements": [
{ "type": "trust", "min_score": 50 }
],
"access": ["profile.*", "events.public"]
},
"premium": {
"label": "Premium",
"requirements": [
{ "type": "payment", "amount": 5, "currency": "usd", "per": "month" }
],
"access": ["*"]
}
}
}Handle 402 Responses
When an agent asks for a gated resource without proof, your platform returns HTTP 402 with a machine-readable body telling the agent exactly what it needs.
Write a ProofVerifier
ProofVerifier
import { ProofVerifierRegistry, resolveAccess, build402Response } from '@eep-dev/gates';const registry = new ProofVerifierRegistry();registry.register({supportedTypes: ['payment'],verify: async (proof, requirement) => {// Ask Stripe if the token is goodreturn await stripe.paymentIntents.retrieve(proof.token).then(pi => pi.status === 'succeeded');},});// In your route handlerconst result = await resolveAccess(proofs, gateConfig, resourcePath, registry);if (!result.granted) {return c.json(await build402Response(gateConfig, resourcePath, proofs), 402);}
2. Requirement Types
Combine any of these using AND/OR logic. The combined type lets you express complex requirement sets.
| Type | What the Agent Provides | Typical Use Case |
|---|---|---|
credential | W3C Verifiable Credential from a named issuer DID | Role/affiliation gating (research, licensed entities) |
identity | Proof of DID ownership (signed challenge) | Know-your-peer; allowlists by DID |
agreement | EdDSA signature over SHA-256 hash of a licence doc | Non-commercial or research usage terms |
data_request | Signed VP + W3C DPV purpose declaration | Quid-pro-quo data exchange |
payment | On-chain transaction hash verified at publisher address | Micropayment for premium data / compute |
combined | AND/OR combination of any of the above | Regulated or high-value resources |
3. Commerce Negotiation
If a service is negotiable, agents and entities trade offers over WebSocket:
Negotiation Flow
// Agent sends offerws.send(JSON.stringify({type: 'commerce', action: 'offer',data: { pricing: { model: 'fixed', amount: 50, currency: 'usd' } }}));// Entity countersws.send(JSON.stringify({type: 'commerce', action: 'counter',data: { pricing: { model: 'fixed', amount: 75, currency: 'usd' } }}));// Agent acceptsws.send(JSON.stringify({type: 'commerce', action: 'accept',data: { negotiation_id: 'neg_abc' }}));
4. Service Listings
Entities publish a machine-readable catalog of what they offer:
{
"entity_did": "did:web:example.com:u:alice",
"services": [
{
"id": "svc_consultation_30",
"name": "30-Minute Strategy Consultation",
"category": "consulting",
"pricing": { "model": "fixed", "amount": 75, "currency": "usd" },
"delivery": "realtime",
"negotiable": true,
"status": "active"
}
]
}5. Access Patterns
Wildcard syntax for matching resources to tiers:
| Pattern | Matches |
|---|---|
* | Everything |
profile.* | profile.bio, profile.skills, profile.contact.email |
content.papers.* | content.papers.abstract, content.papers.full_text |
events.public | Only events.public, nothing else |