Repository navigation
Eure website - #730
Merged
Merged
Eure website#730
Conversation
EURe moves into @fretchen/chain-utils (getSettlementTokens: 18 decimals, Monerium EURe v1, transferMethod permit2); the website-facing getStablecoins stays USDC+EURC so the buyer side is untouched until its own PR. All three scw_js sellers price EURe (image env EURE_PAYMENT_AMOUNT, search/fetch literals, chat on Mistral's EUR card via tokensToCost's decimals rescale), their 402 entries carry extra.assetTransferMethod: "permit2" and the challenge advertises eip2612GasSponsoring, and the claim cron enumerates getSettlementTokens so EURe channels are claimed. The facilitator reads the shared registry, dropping its local EURE_ADDRESSES (behavior-identical).
Each _buyer notebook's spend-control allowlist decides which non-registry token is payable, so EURe needs an entry like EURC's: genimg on Base mainnet (with its own 18-decimal cap — the 6-decimal figure would cap it at 10⁻¹²), sc_llm on both Base networks (the default Base Sepolia run pays sandbox EURe), search on Base mainnet.
…inal facilitatorFeeFor (new fee_config.ts, pure and unmockable-by-proxy) resolves the fee in each token's own atomic units from /supported's facilitatorFees .assets, falling back to the nominal flatFee only for 6-decimal tokens and returning null (unknown, never a guess) otherwise. The fee-allowance script and the claim cron both used the nominal figure for every token: an 18-decimal EURe allowance divided by the 6-decimal 10000 reported a real 0.98-EURe approval as 98000000000000 settlements, and --approve would have written 10⁻¹² EURe over a healthy allowance. The parse is per-entry safe too: one malformed asset no longer nulls the whole config (which read as "no fee configured" and silently disabled the checks). Encoded as regressions: 0.98 EURe = 98 claims, empty assets on an old facilitator = no runway reported for EURe.
The quote cell divided every accepts[].amount by 1e6 — the same 6-decimal assumption the fee script had — so an EURe offer would have printed its price twelve orders of magnitude too large, and the startup log still claimed the server prefers EURC. Per-token decimals now, and the log names EURe as the preference.
…he claim path in the blast radius The security review of the EURe seller-side branch found the gap: buyer deposits escrowed in batch-settlement channels (USDC, EURC and now EURe on Base) had no asset row, and a stalled claim sweep had no blast-radius entry. Both name the property that matters — a stalled claim delays the buyer's escrow, the withdraw path is the buyer's own, so nothing is lost.
The seller-PR sentence said the website still pays only USDC/EURC until its buyer-side PR — this branch is that PR, so the sentence was stale guidance for every agent loading the skill. It now names the website's actual reads (getSettlementTokens/findSettlementToken, EURe default, per-token spend cap) and keeps the getStablecoins boundary explicit: nothing should read it for EURe.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.