Build on how people feel.
Without holding it.
The oracle is the layer that makes EmotiLink infrastructure rather than an application. It turns authorized signals into states and proofs that any system can request, verify and act on — and it hands over none of the material underneath.
- Interface
- Request a claim. Receive a verifiable answer.
- Availability
- Phase 04. Design partnerships open now.
- Liability
- Data you never received is data you can never leak.
Ask a question. Not for a person.
Integration is a shift in what you request. Instead of a profile you must then defend, you ask whether a condition holds — and get an answer the network has already verified.
Is this person receptive to a suggestion right now?
EmotionState
- emotion:
- "low_receptivity"
- intensity:
- 0.71
- timestamp:
- "2026-09-07T09:22:14Z"
- sources:
- ["node.local", "calendar.api"]
- did_signature:
- "0x8f2a…c41d"
Held encrypted under the person's own key. Not in our database, not in a log, not on a chain.
EmotionalStateProof
- claim:
- receptivity_band == LOW
- satisfied:
- true
- proof:
- "zk:0x3c9f…7e22"
- validators:
- 7 / 7 agreed
- expires_in:
- "15m"
- reveals:
- null
Suppress the prompt. Retry when the band clears.
Authorized by did:emoti:0x9c…4f · Revocable at any time · Scope expires automatically
Five lines, and none of them are negotiable.
- You receive
- A claim, a boolean, a proof and an expiry.
- You never receive
- The emotion state, the signals, or an identifier you can resolve.
- You cannot
- Retain, re-derive, correlate or resell what you were never given.
- You must
- Declare the claim you are asking for, before you ask it.
- The person can
- Revoke your scope at any moment, without notifying you first.
Four kinds of system, one integration shape.
Web2 or Web3, the request is identical, because the oracle sits above that distinction rather than inside either side of it.
AI systems
Emotional and behavioral context for models that currently infer it badly from behavioural exhaust.
Suppress a prompt when receptivity is low, instead of learning that lesson from a churn metric.
dApps
Client-side risk signal at the moment of a transaction, without a wallet learning anything about its owner.
Hold a transfer when the session stops behaving like the person who owns it.
DAOs
Participation and sentiment conditions that can be verified rather than self-reported.
Weight a signal by verified participation without publishing who participated.
Web2 products
The same emotional context, through a conventional API, with the same guarantee attached.
A support queue that routes on state, and stores none of it.
An application does not need to know the underlying emotional data in order to use the information produced from it.
Why a proof is better for you, not only for them.
Personal data is a liability with a long tail: retention obligations, breach exposure, jurisdictional headaches, and a compliance surface that grows every year. A proof has none of that shape.
Nothing sensitive to exfiltrate from your systems.
Proofs expire. There is no schedule to argue about.
Data that never moved has no border to cross.
Authorization is carried by the proof itself.
A small number of teams, early.
The oracle surface arrives in Phase 4, and what it looks like should be shaped by the people who will build on it. If your product would be better knowing less, we would like to talk now.
No tracking pixel on this page · Consent before signal · Always