01 System architecture
From personal intelligence
to collective behavior.
People’s account histories contain years of preferences and behavior. TasteID connects those histories with permission, interprets the activity, and builds knowledge about the things people interact with. One person’s profile gives an agent context. Patterns across consenting people give a business audience intelligence.
Music is the first vertical. TasteID pools track identities into a shared catalog and enriches the audio for reuse across listeners. The larger ambition is a graph connecting people, preferences, and what they listen to, watch, and buy.
HCP is the proposed compensation interface beneath that graph. It links a permitted use to a contribution record, a declared allocation rule, and a funded payment obligation. TasteID would be its first application and operator; other applications could implement the same interface.
Private, off-chain computation
Versioned data + scoped grants
Personal context or audience patterns
Eligible inputs + allocation policy
Verification & payment
Bound to the approved request
Committed execution + funded pool
Private ledger + payout receipts
Working foundation
TasteID’s music capture, audio enrichment, profiles, recommendations and compatibility are live. Google’s CASA security assessment is passed.
Proposed protocol work
Scoped buyer grants, commercial queries, user payouts, contribution proofs and HCP settlement remain to be implemented and validated.
The first proof should be narrow.
Start with a bounded aggregation and allocation program over committed features. Prove which eligible inputs that program used and that the resulting shares follow its declared rule. Proving raw-data authenticity, model inference, or an agent’s entire reasoning process are separate problems.
02 Query lifecycle
One authorized use.
A traceable obligation.
Permission to capture an account history is separate from permission to use it for a buyer’s query. A downstream grant must identify the buyer, purpose, data scope, use class, output limits, duration and compensation terms. Personalization, aggregate analysis, export and training are distinct uses.
| Record | What it must identify |
|---|---|
| Dataset / artifact | Source, version, transformation or model version, subject reference and integrity commitment. |
| Grant snapshot | Authorized parties, purpose, scope, output policy, expiry, terms version and revocation epoch. |
| Request / quote | Authenticated buyer, delegated caller, exact query, approved program, price, asset, destination, expiry and idempotency key. |
| Use / allocation | Input and output commitments, program version, eligible contributors, allocation rule, fulfillment evidence and consumer pool. |
| Payment / settlement | Verified funding, its reserved amount, earnings entries, payout destinations, adjustments and settlement references. |
- Authorize and quote. Authenticate the buyer and agent delegation; evaluate active grants and output controls; quote the specific permitted request. Payment is not authorization to receive personal data.
- Fund the request. Use x402 payment requirements and verified settlement. The initial design waits for confirmed buyer funding before release. x402 facilitator reference ↗
- Prepare the answer. Run the approved program over a committed input set. Produce the bounded output, private contribution trace and proposed allocation proof.
- Verify, recheck and fulfill. Check the proof and current permission state, then publish the authorized result through the release gateway. Persist a fulfillment receipt tied to its output commitment.
- Accrue and pay. Finalize eligible earnings from funded, fulfilled use. Reconcile them to reserved funds and settle through the selected payout mechanism.
HTTP delivery, database writes and a chain transaction are not one atomic operation. Durable states and recovery rules must connect them. Fulfillment here means authorized publication of the result; it does not prove the buyer read it or found it valuable.
03 Proof & trust model
Prove a defined computation.
Name the remaining trust.
A signed list of “records touched” is not enough. An operator could omit contributors or manufacture a trace. The proof must bind the trace and allocation to execution of the approved program over the committed input set, and bind that execution to the paid request.
Candidate proof statement
Approved request + program + authorized input commitment
Output commitment + eligible contributions + allocation root
- Public inputs
- Request hash; program and verifier versions; input, grant and output commitments; policy epoch; allocation policy hash and root; asset; consumer pool; settlement domain.
- Private witness
- Feature records and commitment openings; grant evidence; execution trace; contributor references; allocation leaves and blinding randomness.
- Required constraints
- Input membership; execution of selection and aggregation; grant eligibility under the committed policy snapshot; contributor deduplication; integer allocation and conservation; binding to this request and settlement domain.
The candidate proof covers only the specified program. If an answer includes unproved model inference, the receipt must identify that boundary. The proof system, commitment construction and circuit have not been selected.
| Potential guarantee | Remaining assumption |
|---|---|
| Computation matches committed inputs | The source data is authentic, complete and representative. A commitment does not prove those properties. |
| Use fits a grant snapshot | The permission authority recorded a valid grant; the gateway checks its current state and prevents revoked releases. |
| Shares follow the declared rule | The rule is economically appropriate. Recorded participation is not proof of causal value to an answer. |
| Eligible IDs are counted once | The identity layer resists duplicate people and fraudulent data. Wallets and internal IDs do not prove personhood. |
| Verification need not reveal histories | The initial operator and managed prover may still see inputs; commitments and public settlement metadata can leak information. |
The verifier cannot detect uses outside the instrumented execution path, force every outside buyer to participate, or prove that a result is useful. HCP aims to make a defined funded obligation verifiable, rather than claiming to eliminate all trust.
04 Worked example
An audience answer.
A funded contributor pool.
“Which audience groups are most likely to connect with this release?”
An approved business asks an aggregate question. The operator selects an authorized cohort, runs the declared matching and aggregation program, and returns audience patterns under a defined output policy. Private contribution references support accounting; the business does not receive a list of identified listeners.
Synthetic fixture · Illustrative terms only
This arithmetic assumes 10,000 eligible contributor IDs, equal shares, a test asset with six decimals and zero network fee. It is not a measured query, a live cohort, or a chosen commercial fee.
For this fixture, one eligible contributor counts once per fulfilled query, regardless of records, plays or reads. Eligibility includes the authorized inputs used by the declared computation—not just the people in the final audience segment.
poolUnits = 8_000_000
eligibleCount = 10_000
baseUnits = floor(
poolUnits / eligibleCount
) // 800
remainder = poolUnits % eligibleCount // 0
// Each contributor accrues 0.0008 USDC.For a nonzero remainder, a committed deterministic ordering assigns the extra smallest units. The proof checks the sum and each eligible allocation. Earnings can accumulate before a payout; sending a transaction to every person on every query is not required.
Separate the pool from the platform’s margin.
Settled proceeds − refunds
= contributor pool + platform fee + separately charged payment costs
Platform margin
= platform fee − query compute − proving − operating costs
Actual pricing, fee split, payout thresholds and minimum cohort size remain product decisions. A cohort count alone does not establish anonymity, data quality or representative coverage.
05 Candidate interfaces
Portable receipts.
Explicit settlement bindings.
The interoperability unit is a verifiable use receipt, not a public registry of people’s histories. The following is a design sketch for discussion, not an implemented API, contract ABI or accepted standard.
UseReceipt {
version, operatorId,
requestHash, programHash, verifierVersion,
inputCommitment, grantCommitment, policyEpoch,
outputCommitment, contributionCommitment,
allocationPolicyHash, allocationRoot,
paymentRef, asset, consumerPoolUnits,
settlementDomain, expiresAt, nonce,
fulfillmentRef
}requestHash binds the buyer, delegation, purpose, input scope, output policy and quote. settlementDomain binds the network, contract and protocol version. fulfillmentRef is authenticated gateway evidence of authorized publication, not cryptographic proof that the buyer consumed an HTTP response.
What settleQuery would need to enforce
settleQuery(statement, proof):
require supportedProgramAndVerifier(statement)
require validDomainAndExpiry(statement)
require authenticatedEligibleFulfillment(statement)
require requestMatchesVerifiedFunding(statement)
require sufficientUnallocatedFunding(statement)
require notAlreadyFinalized(statement.requestHash)
require verifyBoundExecutionAndAllocation(proof, statement)
reservePool(statement.paymentRef,
statement.allocationRoot,
statement.consumerPoolUnits)
finalizeRequestAndEmitReceipt(statement)The pool must be funded and reserved exactly once. A payment cannot back multiple independent obligations. A funding adapter must reconcile the x402 collection to escrowed assets or a contract-controlled balance; a transaction hash alone is not spendable backing. The contract also needs authenticated issuers, version governance, emergency controls and safe token handling; the sketch is not production Solidity.
A batch distributor or Merkle-claim contract could discharge the obligation. Claims must bind the funded batch, leaf index, amount and authorized destination, and prevent duplicate withdrawal. Destination enrollment, key recovery, payout timing and custody are open design choices.
x402 payment encoding should use a pinned, tested SDK. Typed receipts may use EIP-712, which does not itself provide replay protection; explicit nonces, domain checks and request-finalization state remain necessary. x402 v2 reference ↗
06 Reliability & privacy
Keep the books correct.
Keep access scoped.
Funding
Quoted → pending → settled
Refunds tracked separately
Delivery
Reserved → prepared → released
Or blocked / failed
Earnings
Allocated → payable → settled
Corrections are linked entries
Use integer smallest-unit amounts with an explicit asset and network. Keep consumer principal, platform revenue and payment costs separate. Adjustments are append-only; reconciliation connects every obligation to eligible funding. Withdrawing access does not erase already-earned payments.
| Event | Required behavior |
|---|---|
| Grant revoked during execution | Serialize withdrawal and release at the gateway. Block publication if withdrawal wins; reconcile settled funds under the disclosed refund policy. |
| Payment settles; delivery fails | Retain recoverable state. Retry only while authorized, or refund. Do not silently record a fulfilled use. |
| Duplicate request / settlement timeout | Reconcile the existing request and payment before charging again. One eligible fulfillment creates one allocation. |
| Cached or derived response | Recheck current authorization before returning data. Track input lineage and apply the declared paid-use rule to reuse. |
| Invalid proof / insufficient funding | Do not finalize or reserve an unfunded pool. Keep the authorized request recoverable or refundable. |
| Replayed claim / changed destination | Check claim state, network, batch and enrolled recipient. Require authenticated destination changes and defined recovery. |
Private histories stay off-chain.
Keep source histories, grants, contribution-to-person mappings and wallet enrollment in controlled private storage. A commitment is not encryption. A managed prover may access its witness, and public transfers can reveal timing, amounts and relationships. Blinding, batching and identifier design need a separate leakage analysis.
Aggregate outputs need suppression, query limits and protection against repeated-query differencing. Derived profiles can still be personal data. Revocation blocks future use; deletion must propagate through personal artifacts and caches. Neither can recall plaintext already disclosed or reverse prior model training.
The x402 payment-identifier extension supports payment deduplication; the application must still reconcile access and earnings. x402 batch settlement concerns buyer payment authorization and redemption. Batching payouts to human contributors is a separate HCP design.
07 Network & incentives
An interface other operators
can verify and implement.
The long-term vision is a network of permissioned knowledge. A query could span graphs operated by different applications. Each operator would enforce its own grants and produce a receipt for its contribution and funded share; a coordinator would compose the result under disclosed terms.
That requires more than a common payment address. Cross-operator identity deduplication, grant freshness, overlapping contribution, query composition, coordinator fees and refunds all need explicit rules. A receipt interface is the starting point—not evidence those problems are solved.
TasteID, the company
Builds capture and intelligence products, serves queries and retains a platform fee. Personal utility can bring people into a paid intelligence network.
HCP, the proposed protocol
Defines verifiable contribution and settlement records other operators could implement. Its value depends on useful independent adoption, not a mandatory TasteID database.
Pay for eligible use, not manufactured activity.
Personal history, shared object descriptors and model outputs are different contributions. Their rights and compensation policies may differ. The example’s equal split is an auditable first experiment, not a claim to have solved marginal value. The rule must be declared before a buyer pays.
Paying per imported record or synthetic action could reward spam. Source provenance, duplicate-account defenses, bot detection and self-dealing controls must sit alongside the proof system. Proving an allocation over fraudulent inputs does not make it valuable.
HCP is a working protocol proposal. No HCP ERC has been submitted or accepted, and no HCP verifier or settlement contract is deployed. The first interoperability test is an independent client validating the same receipts and rejection cases.
08 Implementation path
Make the guarantees
measurable.
Build commercial usefulness and correct accounting first, while prototyping a bounded proof. These are acceptance milestones, not announced dates or completed capabilities.
| Milestone | Evidence of completion |
|---|---|
| 1 · Scoped use | An approved caller receives only a permitted output; expiry and withdrawal block new and queued releases. |
| 2 · Paid fulfillment | One verified payment reconciles to one authorized publication, including retry, timeout and refund cases. |
| 3 · People’s earnings | A contributor traces an earned amount to eligible use, a versioned allocation policy and a reconciled payout. |
| 4 · Bounded proof | A verifier accepts valid execution and allocation, and rejects omitted contributors, changed inputs, altered output, wrong pool and replay. |
| 5 · Independent implementation | A second client checks receipt bindings, verifies the proof and passes the same negative conformance cases. |
Benchmark the complete cost of an answer.
Run synthetic cohort sizes including 10,000 contributors. Measure witness generation, peak memory, proof time at p50/p95, proof size, verification cost, query compute, payout batching and recovery behavior. Report cost per fulfilled query and per contributor. No performance or profitability result is claimed yet.
Decisions before a funded pilot
Choose the supported query program, permitted source uses, grant authority and freshness rule; the proof backend and key governance; the eligibility and allocation policy; payment collection and custody; refund treatment; recipient enrollment and recovery; and the privacy threat model.
The proposed first buyer rail is x402, with USDC on Base as a candidate settlement asset and network. It is a concrete starting point, not a required partner, exclusive chain, or deployed integration.