Follow-up to #545 (the OrderBuilder constructor). Ergonomics for setting a CoW order's expiry.
What
Give the order builder two ways to set expiry:
valid_to(secs) sets an absolute expiry, the CoW validTo unix timestamp (u32 seconds since the epoch, crates/cow-venue/src/order.rs).valid_for(now, duration) sets a relative expiry: it takes the current time and a duration and computes valid_to = now + duration, so a caller writing "expire in one hour" does not hand-roll the arithmetic.
Why
OrderBody::sell/buy currently take valid_to: u32 as a required constructor argument, and every caller that wants a relative expiry recomputes now + n by hand (see the valid_to_in helper in twap-monitor). A valid_for on the builder makes the common "valid for N seconds from now" case a one-liner and keeps the arithmetic in one place.
Design point: where does "now" come from
A wasm guest has no ambient wall clock. std::time::SystemTime is unavailable, and keepers already read the current time from the dispatch tick's epoch_s (the block timestamp, epoch_s: block.timestamp / 1000). So valid_for must take now explicitly rather than read a clock: valid_for(now: u32, duration). Passing an ambient now would require a host clock seam the builder should not depend on.
Open sub-choice: the duration argument type. std::time::Duration is the idiomatic Rust type, but validTo is u32 seconds and the guest works in u32 epoch seconds, so a Duration would need a checked conversion to u32 seconds (saturating or erroring on overflow). Recommend u32 seconds to match the wire and the tick, and to avoid a Duration -> u32 truncation surprise; a Duration overload can be added later if a caller wants it.
Scope
Add both to the builder in crates/cow-venue/src/order.rs alongside the required-args constructor from #545. Keep the required valid_to constructor argument, or move it behind these setters, whichever reads cleaner once #545 lands. Update the twap-monitor valid_to_in caller to use valid_for. Saturate rather than wrap on now + duration overflow.
Acceptance criteria
The builder exposes both an absolute valid_to and a relative valid_for(now, duration), the addition saturates on overflow, and at least one production caller uses valid_for instead of hand-rolled arithmetic.
What
Give the order builder two ways to set expiry:
valid_to(secs)sets an absolute expiry, the CoWvalidTounix timestamp (u32seconds since the epoch,crates/cow-venue/src/order.rs).valid_for(now, duration)sets a relative expiry: it takes the current time and a duration and computesvalid_to = now + duration, so a caller writing "expire in one hour" does not hand-roll the arithmetic.Why
OrderBody::sell/buycurrently takevalid_to: u32as a required constructor argument, and every caller that wants a relative expiry recomputesnow + nby hand (see thevalid_to_inhelper in twap-monitor). Avalid_foron the builder makes the common "valid for N seconds from now" case a one-liner and keeps the arithmetic in one place.Design point: where does "now" come from
A wasm guest has no ambient wall clock.
std::time::SystemTimeis unavailable, and keepers already read the current time from the dispatch tick'sepoch_s(the block timestamp,epoch_s: block.timestamp / 1000). Sovalid_formust takenowexplicitly rather than read a clock:valid_for(now: u32, duration). Passing an ambient now would require a host clock seam the builder should not depend on.Open sub-choice: the
durationargument type.std::time::Durationis the idiomatic Rust type, butvalidToisu32seconds and the guest works inu32epoch seconds, so aDurationwould need a checked conversion tou32seconds (saturating or erroring on overflow). Recommendu32seconds to match the wire and the tick, and to avoid aDuration -> u32truncation surprise; aDurationoverload can be added later if a caller wants it.Scope
Add both to the builder in
crates/cow-venue/src/order.rsalongside the required-args constructor from #545. Keep the requiredvalid_toconstructor argument, or move it behind these setters, whichever reads cleaner once #545 lands. Update the twap-monitorvalid_to_incaller to usevalid_for. Saturate rather than wrap onnow + durationoverflow.Acceptance criteria
The builder exposes both an absolute
valid_toand a relativevalid_for(now, duration), the addition saturates on overflow, and at least one production caller usesvalid_forinstead of hand-rolled arithmetic.