ERC-8348: Financial Lease

Дата публикации: 28-07-2026 06:05:46

@javierpmateos reviewed the updated spec and the PR. This is a strong revision. Four points.
Partial-zero tuples in IFinancialLeaseAnchored. The unanchored case (all-zero tuple) is clean, but the spec should state that a partially zeroed tuple MUST be invalid: either all three of (chainId, registry, anchorId) are zero, or all three are set. Without that rule, a lease returning a nonzero anchorId with a zero registry is ambiguous, and every consumer defines its own handling.
Small terminology point: a uint256 chainId is an EIP-155 chain ID; CAIP-2 is normally a string identifier such as eip155:1. Either representation is workable, but the comment should describe the value returned.
asOf semantics in inputFreshness. The text describes asOf as the timestamp of the datum, but the reference implementation currently sets it to block.timestamp when the servicer submits the update. Those can diverge materially: a collections figure observed at month-end but reported two weeks later is fresh by report time and stale by observation time.
If asOf is intended to mean report time, I would name it accordingly. If it is intended to mean observation time, the servicer should supply it, with report time separately available.
Who sets maxStaleness? The text calls it issuer-declared, but the reference implementation allows the authorized servicer to set it in updateServicing. That is a meaningful governance choice, since a servicer can widen the tolerance applied to its own attestations. Either make it issuer/configurer-controlled policy, or describe it as servicer-declared and make that trust assumption explicit.
Closed enum versus extensible identifiers. ServicingInput covers leasing today, but lease structures with inputs outside the five, such as residual-value appraisals, guarantor status, or collateral substitution, would need an interface change. Have you considered a domain-separated bytes32 input identifier with the five base inputs as named constants? That extends without touching the interface, as with indicators, event types, and party roles in our family.
On freshness composition, the separation now looks clean: ERC-8348 can expose the freshness of lease-specific inputs, while ERC-8330 expresses publication and valuation freshness for a resulting NAV snapshot. I would avoid making an automatic rule that equates a NAV valuationTimestamp with the oldest lease input, since that relationship depends on the valuation methodology and the materiality of each input.
The enforcement-isolation test is the right safeguard. It makes the claim that servicing attestations are advisory, rather than lease-state-changing controls, directly testable.

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

#	Наименование новости	Тональность	Информативность	Дата публикации
1	ERC-8337: Agent Memory State	0	7.65	26-07-2026
2	Proposing a family of candidate ERC interfaces for titled asset infrastructure — architecture review	0	7.85	27-07-2026
3	ERC-TBA: Prediction Market CTF Wrapper	0	11.4	27-07-2026
4	ERC-8004: Trustless Agents	0	8.54	27-07-2026
5	EIP Editing Office Hour (EIP + ERC ) Meeting #108, July 28, 2026	0	18.32	27-07-2026
6	ERC-8330: Subject-Linked NAV Snapshot Oracle	0	6.14	27-07-2026
7	EIP-8037: State Creation Gas Cost Increase	0	19.67	28-07-2026
8	ERC-8312: Bounded Agent Actions	0	12.74	27-07-2026
9	EIP-8151: Account Code Restricted ecRecover	0	5.6	28-07-2026
10	All Core Devs - Testing (ACDT) #90, August 3, 2026	0	15.62	28-07-2026

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