Agent Legal Context
Specification

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

LevelMechanismTierLegal Strength
PassiveTransaction + terms registryTier 1Weakest (established law)
ActiveEIP-712 signature on contentHashTier 2Strong (affirmative consent)
ScopedActive + terms policy complianceTier 3Strongest (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
)
FieldTypeDescription
contentHashbytes32Hash of the terms document being accepted
acceptoraddressAddress signing the acceptance (agent or human)
principaladdressHuman principal's address. If the acceptor IS the principal, set to acceptor.
authorizationRefbytes32Reference to the authorization grant. 0x0 if not applicable.
timestampuint256Unix timestamp of acceptance
expiryuint256Unix 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
)
FieldTypeDescription
contentHashbytes32Hash of the final agreed terms document
partyAaddressFirst party (agent or human)
partyBaddressSecond party (agent or human)
principalAaddressHuman principal behind partyA
principalBaddressHuman principal behind partyB
authorizationRefAbytes32PartyA's authorization grant reference
authorizationRefBbytes32PartyB's authorization grant reference
timestampuint256Unix timestamp of agreement formation
disputeResolveraddressDispute 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:

  1. Who authorized the agent? The human's root key authorized the agent's key. The authorization is on-chain and auditable.
  2. What scope of authority? The authorization includes constraints: spending limits, expiry, and (via the tokenizer) legal scope -- what terms the agent can agree to.
  3. Did the agent act within scope? The terms validation resolver can verify that the accepted terms fall within the agent's terms policy.
  4. Can you trace back to the human? Yes: human root key, authorization grant transaction, agent key, terms signature, IntegraRecord. Every step is independently verifiable.