ERC-TBA: Agent Credit Backers

[priors-agents]

A line of credit to an agent is a bet on whoever stands behind the agent. This draft lets a third party (a staker, a collateral vault, an insurer) stand behind a lender’s line to an agent identity and absorb its defaults, with the identity owner’s EIP-712 consent. The lender asks the backer before each draw (canBorrow), tells it of each draw (onBorrow), and on a default takes the principal from the backer and tells it (onDefault, with what was paid); lowered, removed or replaced lines are told once each (onRelease). Neither a backer nor the lent asset can block a repayment, a default or a removal: notifications run with a fixed gas limit, failures are logged, and calls to the asset are bounded too. It extends the Agent Credit Lines draft (ERC-TBA: Agent Credit Lines).

• Repository (text, reference lender and backer, Foundry tests): GitHub - priors-agents/erc-credit-backer-hooks: Draft ERC (Agent Credit Backers): third parties that stand behind a lender's line to an agent identity and take its loss, through lender hooks · GitHub
• It was raised first on ERC-8210’s thread (ERC-8210: Agent Assurance - #50 by priors-agents), whose “Delegated Funding (Reserved)” section leaves third-party Backers to “a separate ERC”. This is its own thread, as the ERC process asks; if ERC-8210’s authors would rather fold it into that section, we would.
• The reference implementation is not audited and must never be deployed without an external audit.

Questions for lenders, backers and ERC-8210’s authors:

1. On a default the lender takes the principal, then tells the backer. Notify-then-take would let a collateral vault convert collateral inside the hook, at the cost of a call that could fail before the loss is taken. Is take-then-notify the right default?
2. Notifications get a gas limit the lender fixes, of at least 100,000. Is that floor right for backers that keep their own accounts?
3. ERC-8210’s depositFor(agent, amount) funds an agent directly; here a backer stands behind a lender’s line. Should one standard cover both?

[Zealynx]

Take-then-notify seems right to me, and there’s one more reason for it: markDefault is open to anyone once defaultableAt passes, so under notify-then-take a vault would swap its collateral inside a transaction someone else times and builds around, which is an easy sandwich. A vault backer can read dueAt from loanInfo and convert during the grace window, in its own transaction.

Two things about what happens after a default:

1. In the reference, unpaidLoss only goes up (markDefault adds to it and nothing lowers it), so a backer that comes up short by any amount gets no new credit at that lender again, for every identity it backs there. A way to pay the shortfall in later (anyone sends it, unpaidLoss goes down, with an event) gives a vault that converts slowly a way back, and gives the “outside this proposal” sentence somewhere to point.

2. Once a loan is Defaulted, repay reverts and amountDue returns 0, so if the agent turns up with the money later there’s no on-chain path for it, and the backer that paid has no claim on it. For an insurer that recovery is a big part of the economics. I’d either keep a defaulted loan repayable, with the proceeds going to the backer up to what it paid, or say in the text that recovery happens off chain.

On the 100,000 floor: it’s comfortable for bookkeeping like StakeBacker’s, a few storage writes and one approve on a token the default has already touched. On ERC-8210, I’d keep the two apart: money from depositFor is the agent’s to spend, while a backing is a claim only the lender can use, and only on a default.