ERC-TBA: Agent Repay-First Payees

Дата публикации: 25-10-2026 18:22:37

@Revinand You’re right. ERC-8183 takes submit only from the job’s provider (its reference implementation takes setBudget only from the provider too) and pays the provider on complete. The payee could make neither call, so a job assigned to it could only end in a rejection or a refund, and the owner’s own wallet fails the provider check.
The payee now makes those two calls itself, in a new optional part, “Acting as an ERC-8183 provider” (GitHub - priors-agents/erc-repay-first-payees: Draft ERC (Agent Repay-First Payees): a revenue address for an agent identity that pays its creditors before its owner · GitHub, commit a3a0d16):
setJobBudget(commerce, jobId, amount, optParams) and submitJob(commerce, jobId, deliverable, optParams) call setBudget and submit from the payee on the ERC-8183 contract named. The owner can call them, or an operator it names with setOperator, so the agent’s working key can submit without holding the identity. Like a beneficiary, the operator lapses once the owner that named it no longer holds the identity.
The payee makes no other call for them. A general forwarded call would let the owner call a token from the payee and move its balance outside a sweep; setBudget and submit move nothing out of it, since a token has neither function and outside a sweep the payee holds no approval.
What complete pays is a plain transfer to the payee, swept like any other revenue.
An adapter as the provider would be paid in the payee’s place and hold each payment until someone moved it on, so readers would have to check its routing too. With the payee as the provider there is nothing to route, and ERC-8183 sets a job’s provider once, before funding. The owner can still take new jobs under another provider, as with any advertised address, so Security Considerations ask creditors that count on job revenue to check that the jobs name the payee.
Your integration test is in: with a creditor owed 30, the owner proposes 50 through the payee, the client funds, the owner’s own address fails the provider check, the payee submits, the evaluator completes, the job pays the payee 50, and a sweep pays the creditor 30 and forwards 20. Three more cover the operator across a sale, who may call, and a token or an address with no code named as the job contract (50 tests in all). They don’t compile against the previous reference, whose payee has neither call.
The same reading applies to the third address the Motivation named. ERC-8004 sets an agentWallet only with the new wallet’s signature, ERC-1271 for a contract, and the payee validates none, so it can’t be set as one. Validating the owner’s signatures would be the wrong fix: Permit2 and some tokens accept ERC-1271 signatures for transfers, so the owner could sign the payee’s balance away. The draft now says so (commit 4aed089): the payee is a pay-to address and a job’s provider, not the payment wallet, a Rationale point gives the reason, and Security Considerations note that what payers send to agentWallet does not reach the payee. Would a payee that validates only an agentWallet digest it computes itself be worth specifying (ERC-8004’s text leaves that digest’s typed data to the registry), or is a pay-to address enough?

Схожие новости

#	Наименование новости	Тональность	Информативность	Дата публикации
1	ERC-TBA: Agent Credit Backers	0	8.78	26-10-2026
2	ERC-8183: Agentic Commerce	0	7.3	26-10-2026
3	ERC-TBA: Credit-Matched Liquidity	0	9.1	26-10-2026
4	ERC-8004: Trustless Agents	0	8.78	17-10-2026
5	ERC-8337: Agent Memory State	0	7.65	26-07-2026
6	ERC-8348: Financial Lease	0	8.24	28-07-2026
7	ERC-8183: Agentic Commerce	0	5.48	28-07-2026
8	ERC-8107: ENS Trust Registry for Agent Coordination	0	9.8	18-10-2026
9	ERC-8335: Account-Level Transfer With Authorization	0	7	10-07-2026
10	Pre-ERC: Adoption Profile and Reference Kernel for EOAs Adopting Code via SETCODEFROM	0	7	25-10-2026

Классификация: . Схожих патентов: 0. Схожих новостей: 10. Тональность: 0. Информативность: 10.22. Источник: ethereum-magicians.org.