Hi team,
Trynax here, I’ve had a few PRs merged in relay. I figured the team might just be busy on other things at the moment.
I only recently discovered vault-solver, and while digging into the 3F solver I noticed that the current implementation tracks live offer coverage locally, but doesn’t yet seem to track enough remote offer identity/state to support cancel/reprice lifecycle management cleanly.
From reading the current code and vendored 3F API surface, it looks like:
- the solver currently rebuilds local live-offer state from
GET /v1/offer, but only stores (adapter, auction) -> expiry + principal
createOffer currently discards the returned offer ID
- the local tracker does not retain remote
offerId, nonce, status, or expectedReturn
- the solver always uses a fresh monotonic nonce for offer submission, so it is effectively opting out of the API’s “update existing mutable offer for the same
(auctionId, maker, nonce)” path
- the vendored 3F API already appears to expose:
- list offers
- get offer by ID
- cancel offer
Also, docs/3F-PLAN.md already calls out some related deferred lifecycle gaps:
- live offer repricing
- offer cancellation
- dynamic adapter discovery
My read is that a good first step here may be to enrich local 3F offer state before attempting actual repricing/cancel policy. Something like:
- capture/store remote offer IDs from
createOffer
- track enough local state per live offer to reason about lifecycle transitions
- wire the missing cancel/get-by-id API surfaces in the local client wrapper
- expand status handling so canceled/non-covering offers are not treated as live coverage during cache rebuild
- leave actual repricing / cancel-recreate policy for a follow-up step
Before I start working on that, I wanted to sanity-check whether this matches the intended direction for the 3F solver.
Also, would love to ask: is the expected path here update-in-place via reused nonce, cancel/recreate via offer ID, or some combination of both?
Hi team,
Trynax here, I’ve had a few PRs merged in relay. I figured the team might just be busy on other things at the moment.
I only recently discovered
vault-solver, and while digging into the 3F solver I noticed that the current implementation tracks live offer coverage locally, but doesn’t yet seem to track enough remote offer identity/state to support cancel/reprice lifecycle management cleanly.From reading the current code and vendored 3F API surface, it looks like:
GET /v1/offer, but only stores(adapter, auction) -> expiry + principalcreateOffercurrently discards the returned offer IDofferId,nonce,status, orexpectedReturn(auctionId, maker, nonce)” pathAlso,
docs/3F-PLAN.mdalready calls out some related deferred lifecycle gaps:My read is that a good first step here may be to enrich local 3F offer state before attempting actual repricing/cancel policy. Something like:
createOfferBefore I start working on that, I wanted to sanity-check whether this matches the intended direction for the 3F solver.
Also, would love to ask: is the expected path here update-in-place via reused nonce, cancel/recreate via offer ID, or some combination of both?