Proof of Intent
Three levels of proof of intent, EIP-712 typed data schemas, and the chain of trust from agent signature to human principal.
Proof of intent is the core legal validity question: how do you prove that a party (human or agent) intended to be bound by specific terms?
Three Levels
| Level | Mechanism | Tier | Legal Strength |
|---|---|---|---|
| Passive | Transaction + terms registry | Tier 1 | Weakest (established law) |
| Active | EIP-712 signature on contentHash | Tier 2 | Strong (affirmative consent) |
| Scoped | Active + terms policy compliance | Tier 3 | Strongest (negotiated + bounded) |
Level 1: Passive Proof
The transaction itself IS the proof. "You sent payment to this address, the terms registry shows terms X were in effect, therefore you transacted under terms X."
- Legally equivalent to: "You used the website, the TOS was posted, you are bound."
- Established law: Courts have consistently upheld browsewrap and clickwrap agreements under UETA and E-SIGN Act.
- No additional signature required -- the payment signature IS the proof of action.
- Weakest form, but sufficient for low-value, high-volume transactions.
Level 2: Active Proof
A digital signature on the specific contentHash, separate from the payment signature. The agent (or human) signs the content hash before or alongside the transaction.
- Legally equivalent to a wet signature on a contract. Affirmative consent to specific terms, cryptographically provable.
- The signature binds a specific identity (address) to a specific document (contentHash) at a specific time (timestamp).
- Cannot argue "I did not know the terms existed."
Level 3: Scoped Proof
Active proof plus terms policy compliance. The agent's acceptance is validated against the principal's terms policy before being recorded.
- Provides the strongest evidence: the human defined the policy, the agent operated within it, both are provable.
- Complete chain: human intent, authorization grant, agent decision, cryptographic signature, on-chain record.
EIP-712 TermsAcceptance
For Tier 2 explicit acceptance, the counterparty signs the following EIP-712 typed data.
Domain:
{
"name": "Agent Legal Context Protocol",
"version": "1",
"chainId": "<chain_id>",
"verifyingContract": "<integra_record_contract>"
}Type:
TermsAcceptance(
bytes32 contentHash,
address acceptor,
address principal,
bytes32 authorizationRef,
uint256 timestamp,
uint256 expiry
)| Field | Type | Description |
|---|---|---|
contentHash | bytes32 | Hash of the terms document being accepted |
acceptor | address | Address signing the acceptance (agent or human) |
principal | address | Human principal's address. If the acceptor IS the principal, set to acceptor. |
authorizationRef | bytes32 | Reference to the authorization grant. 0x0 if not applicable. |
timestamp | uint256 | Unix timestamp of acceptance |
expiry | uint256 | Unix timestamp after which acceptance is no longer valid. 0 for no expiry. |
Solidity type hash:
bytes32 constant TERMS_ACCEPTANCE_TYPEHASH = keccak256(
"TermsAcceptance(bytes32 contentHash,address acceptor,"
"address principal,bytes32 authorizationRef,"
"uint256 timestamp,uint256 expiry)"
);EIP-712 NegotiatedAgreement
For Tier 3 mutual acceptance of negotiated terms. Both parties MUST sign the same typed data with the same domain separator.
Domain (same as TermsAcceptance):
{
"name": "Agent Legal Context Protocol",
"version": "1",
"chainId": "<chain_id>",
"verifyingContract": "<integra_record_contract>"
}Type:
NegotiatedAgreement(
bytes32 contentHash,
address partyA,
address partyB,
address principalA,
address principalB,
bytes32 authorizationRefA,
bytes32 authorizationRefB,
uint256 timestamp,
address disputeResolver
)| Field | Type | Description |
|---|---|---|
contentHash | bytes32 | Hash of the final agreed terms document |
partyA | address | First party (agent or human) |
partyB | address | Second party (agent or human) |
principalA | address | Human principal behind partyA |
principalB | address | Human principal behind partyB |
authorizationRefA | bytes32 | PartyA's authorization grant reference |
authorizationRefB | bytes32 | PartyB's authorization grant reference |
timestamp | uint256 | Unix timestamp of agreement formation |
disputeResolver | address | Dispute resolution resolver contract for this agreement |
The agreement is formed when both valid signatures exist. Implementations MUST verify both signatures before creating the IntegraRecord.
Solidity type hash:
bytes32 constant NEGOTIATED_AGREEMENT_TYPEHASH = keccak256(
"NegotiatedAgreement(bytes32 contentHash,address partyA,"
"address partyB,address principalA,address principalB,"
"bytes32 authorizationRefA,bytes32 authorizationRefB,"
"uint256 timestamp,address disputeResolver)"
);Domain Separator
Both TermsAcceptance and NegotiatedAgreement use the same domain separator:
bytes32 constant DOMAIN_TYPEHASH = keccak256(
"EIP712Domain(string name,string version,"
"uint256 chainId,address verifyingContract)"
);
// Name: "Agent Legal Context Protocol"
// Version: "1"EIP-712 signatures include chain ID and verifying contract address in the domain separator, preventing cross-chain and cross-contract replay.
Chain of Trust
When an agent signs on behalf of a principal, the chain of trust MUST be provable:
Human Principal (root key)
-> Authorization Grant (on-chain: Tempo Keychain, tokenizer delegation)
-> Agent Key (delegated, constrained)
-> EIP-712 Signature (on contentHash)
-> IntegraRecord (on-chain proof)The authorizationRef field in the EIP-712 data links the agent's signature to the authorization grant, enabling any verifier to trace from the agent's action back to the human's deliberate delegation.
Every link must be provable:
- Who authorized the agent? The human's root key authorized the agent's key. The authorization is on-chain and auditable.
- What scope of authority? The authorization includes constraints: spending limits, expiry, and (via the tokenizer) legal scope -- what terms the agent can agree to.
- Did the agent act within scope? The terms validation resolver can verify that the accepted terms fall within the agent's terms policy.
- Can you trace back to the human? Yes: human root key, authorization grant transaction, agent key, terms signature, IntegraRecord. Every step is independently verifiable.