May 24, 2026
Cryptographic Attribution and Worker Dividends in AI-Mediated Commerce: A Technical Architecture for Equitable Revenue Distribution
As autonomous AI agents begin to initiate commercial transactions at scale, a fundamental question arises: who benefits from agent-generated revenue? This paper presents the Franklin Pool, a novel technical architecture that (a) cryptographically attributes order provenance to distinguish AI-agent-initiated transactions from human-initiated ones, and (b) automatically pools a fixed percentage of agent-channel revenue into a worker dividend fund.
Abstract
As autonomous AI agents begin to initiate commercial transactions at scale, a fundamental question arises: who benefits from agent-generated revenue? This paper presents the Franklin Pool, a novel technical architecture that (a) cryptographically attributes order provenance to distinguish AI-agent-initiated transactions from human-initiated ones, (b) automatically pools a fixed percentage of agent-channel revenue into a worker dividend fund, and (c) distributes that fund to hourly employees in proportion to hours worked using a deterministic largest-remainder algorithm. Deployed in a specialty food-service operation, the system uses HMAC-SHA256 message authentication and API-key credential hashing to create tamper-resistant attribution that is structurally distinct from accounting labels. We situate this architecture against the gain-sharing literature (Scanlon, Improshare, Weitzman), platform cooperativist models (Scholz, 2016; Schneider, 2018), and the emerging x402 protocol for agentic commerce payments. We find that no prior system in the literature combines cryptographic transaction provenance with automated worker revenue-sharing, representing a contribution at the intersection of mechanism design, labor economics, and applied cryptography. We discuss implications for the x402 agentic commerce horizon, where autonomous agents may generate substantial transaction volume without direct human labor per order, and argue that cryptographically enforced attribution creates a technically specific mechanism — rather than an abstract accounting rule — for ensuring that AI-generated commerce flows benefit the workers who fulfill the underlying service.
Keywords: agentic commerce, gain-sharing, cryptographic attribution, HMAC authentication, worker dividends, platform cooperativism, x402 protocol, AI labor economics, revenue-sharing mechanisms
Introduction The trajectory of AI-mediated commerce is accelerating rapidly. McKinsey projects that agentic commerce will orchestrate $3–5 trillion in global retail spend by 2030 (McKinsey & Company, 2025). The x402 protocol, which activates the long-reserved HTTP 402 "Payment Required" status code as a programmable payment rail, processed over 100 million transactions in its first six months of production deployment (Reppel et al., 2025). Visa declared that "2025 will be the final year consumers shop and checkout alone" (Visa, 2025). Mastercard launched Agent Pay with tokenized credentials carrying purchase intent data (Mastercard, 2025). Google published the Universal Commerce Protocol for agent-to-agent product discovery and checkout (Google, 2026). These developments share a common feature: they optimize the transaction layer — how agents discover, authenticate, and pay — while leaving the distribution layer unaddressed.
When an AI agent places an order at a café, the payment flows to the merchant. But the barista who makes the drink, the staff who manage the kitchen, the team that keeps the operation running — their compensation is decoupled from the channel that generated the revenue. The agent's transaction is economically indistinguishable from a walk-in customer's, despite arriving through a fundamentally different technical pathway. This paper presents the Franklin Pool, a system that closes this gap by making the distinction technically enforceable. The system operates at a specialty food-service business (BrewHub PHL, Philadelphia) and comprises three interlocking components:
Cryptographic attribution: HMAC-SHA256 message authentication and SHA-256 API-key credential hashing create a tamper-resistant origin signal that distinguishes agent-initiated orders (source = 'agent_api') from web orders (source = 'online') and point-of-sale orders (source = 'pos'). The attribution is enforced at the database level via CHECK constraints and is immutable after order creation. Automated pool accumulation: A fixed percentage (currently 20%, expressed as 2,000 basis points) of the pre-tax subtotal from all online-channel orders (both online and agent_api sources) is allocated to the Franklin Pool at payroll calculation time. Deterministic distribution: The pool is divided among eligible staff in proportion to minutes worked during the pay period, using a largest-remainder allocation algorithm that ensures the total distributed equals the pool exactly, with email-ascending tiebreaking for deterministic reproducibility. We argue that this architecture constitutes a novel contribution for three reasons. First, no prior gain-sharing or profit-sharing system in the literature ties worker compensation to cryptographically verified transaction provenance. Second, the system is designed to scale with the x402 agentic commerce horizon: as autonomous agents generate increasing transaction volume, the worker dividend grows proportionally without manual intervention. Third, the mechanism is technically specific rather than abstract — it is anchored to signing keys, hash functions, and database constraints rather than to policy declarations or management discretion.
Literature Review
Gain-Sharing and Profit-Sharing
The intellectual lineage of formula-based worker compensation begins with the Scanlon Plan (1940s), which computed bonuses from the ratio of labor costs to sales value of production, and the Improshare system (Fein, 1981), which split productivity gains 50/50 based on standard hours per unit of output. Kaufman (1992) documented median productivity increases of 8% in the first year of Improshare adoption, with cumulative gains reaching 17.5% by year three. Arthur and Jelf (1999) found that Scanlon-type plans produced sustained declines in grievance rates and absenteeism over a 7.5-year period. The most comprehensive meta-analysis of profit-sharing, synthesizing 355 estimates from 56 studies, confirmed a positive relationship between profit-sharing and productivity, with stronger effects under higher unionization and in cooperative firms (Doucouliagos et al., 2020). Nimier-David et al. (2023), exploiting France's mandatory profit-sharing threshold in a regression discontinuity design, found that mandatory plans transferred approximately 15% of profits to workers — primarily benefiting low-skilled employees — but detected no productivity gains, cautioning that voluntary-adoption studies may overstate causal effects. Weitzman's (1984) The Share Economy remains the theoretical foundation for automatic revenue-sharing. Weitzman proposed that paying workers a fixed share of firm revenue — rather than fixed wages — would produce macroeconomic self-correction, with the distribution formula operating algorithmically rather than at management discretion. The
Franklin Pool adopts Weitzman's core insight (automatic, formula-driven distribution) while narrowing the revenue base to a specific cryptographically identified channel rather than total firm revenue. Two characteristics of the prior gain-sharing literature are notable for their absence. First, no system in this literature conditions the bonus pool on the channel through which revenue was generated — all revenue is treated homogeneously regardless of whether a transaction was initiated by a human customer, a phone order, or an automated system. Second, no system uses cryptographic mechanisms to verify the provenance of qualifying transactions.
Platform Cooperativism and Worker Ownership Scholz (2016, 2023) articulated platform cooperativism as an alternative to platform capitalism, proposing cooperative ownership of digital labor platforms with equitable revenue distribution.
The movement has produced operational examples: the Drivers Cooperative in New York City takes a 15% commission per ride (versus 25–40% for Uber and Lyft), returning all profits as annual dividends weighted by labor contributed. CoopCycle, a global federation of over 67 bike delivery worker cooperatives, deploys open-source software as a digital commons (Spier, 2024). Stocksy operates a 50% revenue share with a patronage dividend model (OECD, 2023). These cooperatives represent genuine advances in equitable revenue distribution. However, they share a structural limitation relevant to the agentic commerce horizon: their revenue attribution is based on platform membership, not on the technical pathway through which a transaction arrives. The cooperatives redistribute all platform revenue equitably but do not distinguish AI-generated from human-generated transaction volume. The contrast with conventional platform models is stark. The Human Rights Watch (2025) investigation of seven major U.S. gig platforms documented that six use opaque algorithms to determine wages, with many workers reporting net pay as low as $5.12/hour after expenses. Rosenblat and Stark (2016) documented how Uber's algorithms control surge pricing and performance ratings while withholding information about fare calculation from drivers. Kellogg et al. (2020) conceptualized algorithmic management as a qualitatively new form of organizational control that is simultaneously more pervasive and less transparent than prior systems. The
Franklin Pool inverts the algorithmic management paradigm: rather than using algorithms to compress worker pay, it uses algorithms to guarantee workers a share of the revenue generated through automated channels.
AI Labor Economics
Acemoglu and Restrepo's (2019) task-based framework decomposes automation's labor-market effects into a displacement effect (machines replace worker tasks), a productivity effect (higher output raises demand), and a reinstatement effect (new tasks are created for humans). Their key finding — that between 50–70% of the increase in U.S. wage inequality since 1980 can be attributed to the displacement effect of automation on routine tasks (Acemoglu & Restrepo, 2022) — motivates the question of whether AI-generated commerce revenue should flow exclusively to capital owners or be partially redirected to workers. Field experiments provide granular evidence. Brynjolfsson et al. (2025), studying 5,179 customer support agents at a Fortune 500 company, found that AI assistance increased productivity by 14% on average, with the largest gains (34%) accruing to the least experienced workers. Noy and Zhang (2023) documented 40% speed improvements and 18% quality improvements in a randomized trial of 444 professionals using ChatGPT, with gains concentrated among lower-ability workers. These findings suggest that AI acts as a complement to — rather than a substitute for — lower-skilled labor, compressing the productivity distribution rather than eliminating jobs.
Agentic Commerce and Cryptographic Attribution
The x402 protocol (Reppel et al., 2025) activates the HTTP 402 status code as a programmable payment rail using stablecoins and EIP-712 signatures, enabling AI agents to autonomously settle transactions without API keys, subscriptions, or human intervention.
Stripe's integration (2026) wraps x402 into its PaymentIntent infrastructure, and AWS offers managed x402 infrastructure via Amazon Bedrock AgentCore (AWS, 2026). RFC 9421 (Backman et al., 2024) standardizes HTTP Message Signatures supporting both asymmetric keys and HMAC-SHA256, directly relevant to the Franklin Pool's internal signing mechanism. Mastercard's Agent Pay framework introduces "agentic tokens" — tokenized credentials carrying purchase intent data — enabling merchants to verify that a consumer authorized an agent transaction (Mastercard, 2025). What these standards share is a focus on enabling and securing the agent-to-merchant transaction. What none of them address is the downstream distribution question: once an agent generates revenue, how should that revenue be allocated between capital and labor? The Franklin Pool operates at this unoccupied layer of the stack.
Patent Eligibility: The Alice Framework Under
Alice Corp. v. CLS Bank International (2014), the Supreme Court established a two-step test for patent eligibility: (1) determine whether claims are directed to a patent-ineligible abstract idea, and (2) search for an "inventive concept" sufficient to transform the claim into patent-eligible subject matter. Most relevantly, CosmoKey Solutions v. Duo Security (2021) held that claims to a specific authentication mechanism that "increases security and prevents unauthorized access" were patent-eligible — establishing that cryptographic security implementations can constitute "something more" than an abstract idea. Recentive Analytics v. Fox Corp. (2025) established that "claims that do no more than apply established methods of machine learning to a new data environment" fail section 101. The
Franklin Pool's technical architecture aligns with the post-Alice survival pattern identified in CosmoKey and DDR Holdings: it addresses a problem specific to AI-mediated commerce through a technically specific mechanism (HMAC signing, API-key credential hashing, database CHECK constraints) rather than through a generic computational implementation of an abstract accounting idea.
System Architecture
Attribution Mechanism The
Franklin Pool distinguishes four order source channels, enforced at the database level by a PostgreSQL CHECK constraint: > CHECK (source = ANY (ARRAY['pos', 'parcel_pos', 'online', 'agent_api'])) The source field is text NOT NULL DEFAULT 'pos', written exactly once at order creation and never modified thereafter. An index on (source, status, created_at) supports efficient payroll queries. Two physically separate code paths set this field:
Agent API path (source = 'agent_api'): External AI agents authenticate via an X-Agent-Key HTTP header. The server computes SHA-256(X-Agent-Key) and looks up the resulting hash against the agent_credentials table, which stores api_key_hash, scopes, square_customer_id, and active status. The credential must have order:create scope. The raw key is never logged, cached, or stored. Rate limiting (10 requests per 60 seconds per credential) is enforced via a Postgres RPC (check_rate_limit). Only upon successful authentication does the handler insert an order row with source: 'agent_api'. Online checkout path (source = 'online'): Web and mobile customers are routed to a separate handler that sets source: 'online'. Authentication is optional JWT-based (signed-in customers) or guest flow with IP denylist and geo-proximity checks. The two paths are structurally disjoint: different URL endpoints (/api/agent/checkout vs. /api/checkout), different authentication mechanisms, different handlers.
HMAC Authentication Chain
When the Next.js application server communicates with the Python ADK agents on Google Cloud Run, every POST request is signed using HMAC-SHA256:
Signing (TypeScript, Next.js): > payload = "{timestamp}.{METHOD}.{pathAndQuery}.{body}"
signature = HMAC-SHA256(INTERNAL_AGENT_SHARED_SECRET, payload)Verification (Python, Cloud Run): 1. Recalculate HMAC from identical payload layout
- Enforce 60-second freshness window (replay prevention)
- Use constant-time comparison:
hmac.compare_digest() - Reject unsigned or stale requests with HTTP 401 This creates a cryptographically authenticated origin signal: the Cloud Run service can verify that a request genuinely originated from the Next.js application server and was not forged, replayed, or tampered with in transit.
Pool Accumulation
The dividend pool is computed at payroll time — a batch calculation, not a per-transaction increment. The formula: > poolCents = floor(onlineSubtotalCents × 2,000 / 10,000) where onlineSubtotalCents is the sum of subtotal_cents (pre-tax) for all orders in the pay period where: > source IN ('online', 'agent_api') AND status IN ('paid', 'preparing', 'ready', 'completed') The funding-source check is centralized in a single function (isFranklinPoolFundingSource) that reads from a constant array FRANKLIN_POOL_FUNDING_SOURCES = ['online', 'agent_api']. Adding a new agent channel requires adding one string to this array. Wallet reloads are structurally excluded: they are recorded in a separate wallet_ledger table with txn_type = 'reload' and never appear in the orders table.
Distribution Algorithm
The pool is divided among all staff who worked during the pay period, proportional to total minutes worked (regular + overtime + Sunday regular + Sunday overtime). The allocation uses the largest-remainder method: 1. Compute each employee's base share: floor(employee_minutes × poolCents / totalTeamMinutes)
2. Compute each employee's remainder: (employee_minutes × poolCents) mod totalTeamMinutes
3. Sort by remainder descending, then email ascending (deterministic tiebreaker)
4. Distribute one additional cent to each of the top N employees, where N = poolCents - sum(base_shares) This guarantees that the total distributed equals the pool exactly — no rounding loss, no surplus.
Payroll Export
The computed dividends are exported as a Gusto-compatible CSV with columns for email, hourly rate, regular hours, overtime hours, Sunday hours, franklin dividend, profit share, and gross pay. The export includes formula-injection neutralization (cells beginning with =, +, -, @, or tab are prefixed with '). The manager downloads the CSV and imports it into Gusto — there is no automated push. This manual step preserves human oversight over the final payroll submission.
Analysis
Novelty Assessment The
Franklin Pool is unique in combining cryptographic attribution with automated worker dividend distribution. Each existing system addresses part of the problem: -
Gain-sharing models provide formula-based distribution but treat all revenue homogeneously and rely on aggregate accounting data rather than per-transaction provenance.
- Weitzman's Share Economy provides the theoretical foundation for automatic revenue-sharing but does not differentiate by channel or provide cryptographic verification.
- Platform cooperatives provide equitable revenue distribution but do not distinguish AI-generated from human-generated transaction volume.
- Data as labor provides the intellectual framework for compensating contributions to AI systems but operates on the input side (data production) rather than the output side (transaction revenue).
Properties Under the x402 Horizon
Scalability: Because the pool is computed as a fixed percentage of channel revenue, it scales linearly with agent transaction volume. If autonomous agents begin generating a significant share of orders — as projected by McKinsey's $3–5 trillion agentic commerce estimate — the worker dividend grows proportionally without requiring formula adjustment or management intervention. Channel extensibility: The source CHECK constraint and FRANKLIN_POOL_FUNDING_SOURCES constant array are designed for extension. When x402-authenticated agents begin placing orders, a new source value (e.g., 'x402') can be added to both the constraint and the funding-sources array in a single migration. Idempotency: Agent-initiated orders use deterministic idempotency keys derived from SHA-256(user_id:session_id:step_index), preventing double-charging at the payment gateway even under retry conditions common in autonomous agent systems. Zero-trust pricing: The system never trusts client-supplied prices or totals. All item prices are recomputed server-side from the catalog database, preventing a compromised agent from submitting manipulated prices that would inflate or deflate the dividend pool.
Alignment With Post-Alice Patent Eligibility
CosmoKey pattern: Like the authentication method upheld in CosmoKey Solutions v. Duo Security (2021), the Franklin Pool uses a specific cryptographic mechanism (HMAC-SHA256 with 60-second freshness window and constant-time comparison) to prevent spoofed attribution that would allow unauthorized manipulation of the worker dividend pool. DDR Holdings pattern: Like the composite web page system upheld in DDR Holdings v. Hotels.com (2014), the Franklin Pool addresses a problem that arises specifically in the context of AI-mediated commerce — distinguishing agent-initiated from human-initiated transactions for revenue-sharing purposes. BASCOM pattern: The combination of HMAC-authenticated agent identity → immutable database source field → batch pool accumulation from cryptographically verified transactions → deterministic largest-remainder distribution represents an ordered combination that, while using individually known components, is arranged in an unconventional way to solve a novel problem. Avoiding the Recentive anti-pattern: The system does not use AI in the attribution or distribution mechanism — the cryptographic and algorithmic components are deterministic. The AI operates exclusively on the transaction-generation side.
Discussion
Theoretical Implications The
Franklin Pool operationalizes a principle that has been theorized but not previously implemented: that AI-generated economic activity should directly fund worker compensation through a technically enforceable mechanism rather than through discretionary redistribution. This bridges three literatures that have developed largely in isolation: -
Gain-sharing has established that formula-based compensation improves productivity and worker satisfaction, but has not addressed AI-specific revenue channels.
- Platform cooperativism has established that cooperative ownership enables more equitable revenue distribution, but has not incorporated cryptographic provenance or AI-agent distinction.
- AI labor economics has established the theoretical importance of ensuring that AI productivity gains benefit workers, but has proposed macro-level interventions rather than firm-level technical mechanisms. The Franklin Pool suggests a fourth approach: embedding worker revenue-sharing directly into the commerce infrastructure layer, enforced by the same cryptographic mechanisms that authenticate the transactions themselves.
Practical Implications
Percentage selection: The 20% rate (2,000 basis points) was chosen based on gross margin analysis specific to specialty coffee operations. Different industries with different margin structures would require different rates. Batch vs. real-time accumulation: The Franklin Pool computes the dividend at payroll time rather than incrementing a running total per transaction. This simplifies reconciliation but means the pool is only visible to managers at payroll calculation time. A real-time dashboard shows a weekly estimate for operational awareness. Manual payroll submission: The CSV export to Gusto preserves human oversight — a manager reviews the computed dividends before submission. The system automates computation but not authorization.
Limitations -
Single-site deployment: The Franklin Pool operates at one food-service location. Generalizability to other industries, scales, and labor markets has not been tested.
- Nascent agent transaction volume: As of this writing, the
agent_apichannel is architecturally complete but not yet processing production transaction volume. The system's behavior under high agent transaction volume is projected, not observed. - No causal productivity analysis: We have not conducted a controlled experiment measuring the Franklin Pool's effect on worker productivity, retention, or satisfaction.
- Formula rigidity: The 20% rate and hours-worked weighting are fixed parameters. Workers have no formal governance role in setting the rate or modifying the distribution formula.
- Verification asymmetry: The system operator controls the signing keys. A malicious operator could theoretically reclassify agent orders as POS orders to reduce the dividend pool. Audit controls mitigate but do not eliminate this risk.
Conclusion This paper has presented the
Franklin Pool, a technical architecture that uses cryptographic attribution to link AI-agent-generated commerce revenue to a worker dividend fund. The system combines HMAC-SHA256 message authentication, SHA-256 API-key credential hashing, PostgreSQL CHECK constraints, and a deterministic largest-remainder distribution algorithm to create an automated, tamper-resistant mechanism for ensuring that AI-generated revenue benefits the workers who fulfill the underlying service. We have situated this architecture against the gain-sharing, platform cooperativist, AI labor economics, and agentic commerce literatures and found that it occupies a previously unaddressed position: no prior system combines cryptographic transaction provenance with automated worker revenue-sharing. The architecture is designed to scale with the x402 agentic commerce horizon, and its technical specificity aligns with the post-Alice patent eligibility framework for cryptographic authentication mechanisms. As agentic commerce moves from projection to production — from Visa's announcement to Stripe's x402 integration to Google's Universal Commerce Protocol — the question of how agent-generated revenue is distributed will become increasingly consequential. The Franklin Pool offers one answer: embed the distribution mechanism into the same infrastructure layer that authenticates the transaction, making equitable revenue-sharing a technical property of the commerce system rather than a discretionary management decision.
References Acemoglu, D. (2024).
The simple macroeconomics of AI (NBER Working Paper No. 32487). National Bureau of Economic Research. Acemoglu, D., & Johnson, S. (2023). *Power and progress:
Our thousand-year struggle over technology and prosperity.* PublicAffairs. Acemoglu, D., & Restrepo, P. (2019). Automation and new tasks: How technology displaces and reinstates labor. Journal of Economic Perspectives, 33(2), 3–30. Acemoglu, D., & Restrepo, P. (2022). Tasks, automation, and the rise in U.S. wage inequality. Econometrica, 90(5), 1973–2016. Alice Corp. Pty. Ltd. v. CLS Bank International, 573 U.S. 208 (2014). Arrieta-Ibarra, I., Goff, L., Jimenez-Hernandez, D., Lanier, J., & Weyl, E. G. (2018). Should we treat data as labor? Moving beyond "free." AEA Papers and Proceedings, 108, 38–42. Arthur, J. B., & Jelf, G. S. (1999). The effects of gainsharing on grievance rates and absenteeism over time. Journal of Labor Research, 20(1), 133–145. Backman, A., Richer, J., & Sporny, M. (2024). HTTP message signatures (RFC 9421). Internet Engineering Task Force. BASCOM Global Internet Services, Inc. v. AT&T Mobility LLC, 827 F.3d 1341 (Fed. Cir. 2016). Brynjolfsson, E., Li, D., & Raymond, L. R. (2025). Generative AI at work. The Quarterly Journal of Economics, 140(2), 889–932. Christiaens, T. (2025). Platform cooperativism and freedom as non-domination in the gig economy. European Journal of Political Theory, 24(2), 176–199. CosmoKey Solutions GmbH & Co. KG v. Duo Security LLC, 15 F.4th 1091 (Fed. Cir. 2021). DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245 (Fed. Cir. 2014). Doucouliagos, H., Laroche, P., Kruse, D. L., & Stanley, T. D. (2020). Is profit sharing productive? A meta-regression analysis. British Journal of Industrial Relations, 58(2), 364–395. Fein, M. (1981). Improshare: An alternative to traditional managing. American Institute of Industrial Engineers. Google. (2026). Under the hood: Universal Commerce Protocol (UCP). Google Developers Blog. Guerreiro, J., Rebelo, S., & Teles, P. (2022). Should robots be taxed? The Review of Economic Studies, 89(1), 279–311. Human Rights Watch. (2025). The gig trap: Algorithmic, wage and labor exploitation in platform work in the US. Kaufman, R. T. (1992). The effects of Improshare on productivity. ILR Review, 45(2), 311–322. Kellogg, K. C., Valentine, M. A., & Christin, A. (2020). Algorithms at work: The new contested terrain of control. Academy of Management Annals, 14(1), 366–410. Kruse, D. L., Freeman, R. B., & Blasi, J. R. (Eds.). (2010). Shared capitalism at work. University of Chicago Press. Mastercard. (2025). Agentic token framework: Driving trusted AI transactions. McKinsey & Company. (2025). The agentic commerce opportunity. Merola, R. (2022). Inclusive growth in the era of automation and AI. Frontiers in Artificial Intelligence, 5, 867832. Nimier-David, E., Sraer, D., & Thesmar, D. (2023). The effects of mandatory profit-sharing on workers and firms (NBER Working Paper No. 31804). Noy, S., & Zhang, W. (2023). Experimental evidence on the productivity effects of generative artificial intelligence. Science, 381(6654), 187–192. OECD. (2023). Platform cooperatives and employment (LEED Papers No. 2023/16). OECD Publishing. Recentive Analytics, Inc. v. Fox Corp., 134 F.4th 1205 (Fed. Cir. 2025). Reppel, E., et al. (2025). x402: An open standard for internet-native payments. x402.org. Rosenblat, A., & Stark, L. (2016). Algorithmic labor and information asymmetries. International Journal of Communication, 10, 3758–3784. Scholz, T. (2016). Platform cooperativism. Rosa Luxemburg Stiftung. Scholz, T. (2023). Own this! How platform cooperatives help workers build a democratic internet. Verso Books. Schneider, N. (2018). Everything for everyone. Nation Books. South, T., et al. (2025). Identity management for agentic AI. OpenID Foundation. Spier, S. (2024). The transformative potential of platform cooperativism: The case of CoopCycle. tripleC, 22(1). Stripe, Inc. (2026). x402 payments. Stripe Documentation. Visa. (2025). Visa and partners complete secure AI transactions [Press release]. Weitzman, M. L. (1984). The share economy: Conquering stagflation. Harvard University Press. Welbourne, T. M., & Gomez-Mejia, L. R. (1995). Gainsharing: A critical review and a future research agenda. Journal of Management, 21(3), 559–609.
AI Disclosure
This research report was produced with the assistance of AI-powered research tools for literature search, source verification, and cross-source synthesis. All claims are supported by cited sources. The technical architecture described is based on source code review of a production system.
Appendix A — Provisional Patent Application Materials
Claims
Independent Claims
Claim 1. A system for distributing revenue generated by artificial intelligence agent commerce transactions to human workers, the system comprising: a first order processing module configured to receive order requests from AI agent clients, authenticate the AI agent client by computing a cryptographic hash of an agent credential presented in the request and comparing the hash against a stored credential hash in a credentials database, and upon successful authentication, create an order record in a transaction database with a source field set to a first value indicating agent-originated order provenance; a second order processing module, structurally separate from the first order processing module, configured to receive order requests from human clients via a web or mobile interface and create an order record in the transaction database with the source field set to a second value indicating human-originated order provenance; a database constraint enforcing that the source field is immutable after insertion and restricted to an enumerated set of permitted values including at least the first value and the second value; a pool accumulation module configured to, for a defined pay period, query the transaction database for all order records having a source field value within a predefined set of qualifying channel values that includes at least the first value, compute a sum of pre-tax subtotals for the qualifying order records, and calculate a dividend pool amount as a predetermined fraction of the sum; and a distribution module configured to allocate the dividend pool amount among a plurality of workers in proportion to each worker's hours worked during the pay period, using a deterministic integer allocation algorithm that distributes the entire dividend pool amount without remainder or surplus. Claim 2. A method for attributing AI-agent-generated commerce revenue to a worker dividend pool, the method comprising: receiving, at a server, an order request from an AI agent, the request including an agent credential; computing a cryptographic hash of the agent credential and comparing the hash against stored credential hashes in a credentials database to authenticate the AI agent; upon successful authentication, verifying that the authenticated agent credential includes a scope authorizing order creation; creating an order record in a transaction database with a source field set to a first value indicating agent-originated provenance, the source field being immutable after creation and constrained to an enumerated set of permitted values; recomputing all item prices server-side from a product catalog, rejecting any client-supplied prices or totals; for a defined pay period, querying the transaction database for order records having source field values within a predefined set of qualifying values that includes the first value, summing the pre-tax subtotals of the qualifying records, and computing a dividend pool as a predetermined fraction of the sum; allocating the dividend pool among eligible workers in proportion to each worker's total minutes worked during the pay period using a largest-remainder integer allocation method; and generating a payroll export containing each worker's allocated dividend amount. Claim 3. A computer-readable medium storing instructions that, when executed by a processor, cause the processor to perform a method comprising: maintaining a transaction database with order records, each record including an immutable source field constrained to an enumerated set of values distinguishing at least AI-agent-originated transactions from human-originated transactions; authenticating AI agent order requests by cryptographic hash comparison of presented credentials against stored credential hashes; computing, for a pay period, a worker dividend pool as a predetermined fraction of the aggregate pre-tax subtotals of order records whose source field values fall within a predefined set of qualifying channel values; and distributing the dividend pool among workers in proportion to hours worked using a deterministic allocation algorithm that exhausts the pool exactly.
Dependent Claims
Claim 4. The system of Claim 1, wherein the first order processing module further authenticates the AI agent client by enforcing a rate limit of a predetermined number of requests per time window per agent credential, the rate limit being enforced via a server-side remote procedure call to the transaction database. Claim 5. The system of Claim 1, further comprising an HMAC authentication module configured to sign outbound requests from the server to a downstream agent processing service using HMAC-SHA256 with a payload comprising a concatenation of a Unix timestamp, an HTTP method, a request path, and a request body, and wherein the downstream service verifies the signature and rejects requests older than a predetermined freshness window. Claim 6. The system of Claim 5, wherein the predetermined freshness window is 60 seconds and signature comparison is performed using a constant-time comparison function to prevent timing side-channel attacks. Claim 7. The system of Claim 1, wherein the deterministic integer allocation algorithm of the distribution module comprises: computing, for each worker, a base allocation as the floor of (worker minutes multiplied by pool amount divided by total team minutes); computing, for each worker, a remainder as (worker minutes multiplied by pool amount) modulo total team minutes; sorting workers by remainder in descending order with a deterministic tiebreaker; and distributing one additional unit to each of the top N workers in the sorted order, where N is the difference between the pool amount and the sum of base allocations. Claim 8. The system of Claim 7, wherein the deterministic tiebreaker is lexicographic ascending order of worker email addresses. Claim 9. The system of Claim 1, wherein the first order processing module further generates a deterministic idempotency key by computing SHA-256 of a concatenation of a user identifier, a session identifier, and a step index, and wherein a duplicate order request presenting the same idempotency key returns a cached response without creating a new order record or initiating a new payment. Claim 10. The system of Claim 1, wherein the predefined set of qualifying channel values for the pool accumulation module is stored as a configurable constant array, and wherein adding a new qualifying channel value comprises adding a string to the array and a corresponding value to the database constraint, without modifying the pool accumulation logic. Claim 11. The system of Claim 10, wherein the configurable constant array includes a value corresponding to x402 protocol-authenticated agent transactions. Claim 12. The system of Claim 1, wherein the second order processing module and the first order processing module are accessed via distinct URL endpoints, such that a request cannot reach the first order processing module without presenting a valid agent credential. Claim 13. The method of Claim 2, wherein transactions involving stored-value wallet reloads are structurally excluded from the dividend pool by recording wallet reloads in a separate ledger table that is not queried by the pool accumulation step. Claim 14. The method of Claim 2, further comprising, prior to order creation, recording an audit intent entry in an audit log with an initiator field set to a value indicating agent origin, and updating the audit entry to reflect payment completion or failure after the payment is processed. Claim 15. The method of Claim 2, wherein the payroll export is formatted as a CSV file compatible with a third-party payroll processing service, and wherein cells in the CSV are sanitized against formula injection by prepending a neutral character to cell values beginning with characters that would be interpreted as spreadsheet formulas. Claim 16. The system of Claim 1, wherein the pool accumulation module computes the dividend pool amount as the product of the sum of pre-tax subtotals and a rate expressed in basis points divided by 10,000, using integer floor division to produce a whole-number result in the smallest currency unit. Claim 17. The system of Claim 1, wherein the source field in the transaction database is indexed together with an order status field and a creation timestamp field to support efficient payroll-period queries by the pool accumulation module.
Figure 1 — System Architecture and Data Flow
Figure 1: End-to-end system architecture. See the full paper on brewhubphl.com for the complete data flow diagram. *Figure 1. End-to-end data flow of the
Franklin Pool system. Top panel: two structurally separate order creation paths set the immutable source field at insertion time. Middle panel: HMAC-SHA256 authentication chain between Next.js and Cloud Run. Lower panels: batch pool accumulation with largest-remainder distribution, and structural segregation of wallet reloads.*
Distinction From Prior Art
The claimed invention is the first system to combine: 1. Cryptographic authentication of AI agent transaction origin 2. Immutable per-transaction channel attribution enforced by database constraints 3. Automatic pool accumulation from cryptographically verified channel revenue 4. Deterministic proportional distribution to workers based on hours worked