Polish Fast USDC interfaces #10432
Labels
enhancement
New feature or request
Milestone
Comments
1 task
3 tasks
mergify bot
added a commit
that referenced
this issue
Nov 18, 2024
closes: #10301 ## Description - feat(fast-usdc): .start.js core-eval w/oracle invitations - the pool share brand is called `FastLP` , at least **UNTIL #10432** - needed contract tweak: STUB! makeOracleInvitation , so perhaps this should wait for #10478 - feat(builders): fast-usdc builder w/CLI config for fees, oracle addresses Also, rather than yet another ad-hoc way of passing terms containing amounts from builders to core-eval, this includes `LegibleCapData`, an approach for... - #7309 ### Security Considerations Oracle invitations are sent do parties identified by addresses, so the usual key management issues apply. In order to reduce "which address is for which operator?" hassle, configuration uses a record, like we do for `voterAddresses`, rather than a plain array as in price feed core-eval code. The core eval produces a `fastUSDCKit` including `privateArgs`; this was prompted by testing difficulties: `instancePrivateArgs` is a heap map, not a remotable, so `EV(instancePrivateArgs).get(instance)` is a no-go. But it also usefully avoids handing out all of `instancePrivateArgs` to any core-eval for upgrading this contract. ### Scaling Considerations The core-eval is O(1), I think. It's O(n) in the number of oracle operators, but that number is fixed by proposal time. ### Documentation Considerations The builder CLI args are lightly documented, in the source: ```js /** @type {ParseArgsConfig['options']} */ const optionsConfig = { contractFee: { type: 'string', default: '0.01' }, poolFee: { type: 'string', default: '0.01' }, oracle: { type: 'string', multiple: true }, }; const oraclesRequiredUsage = 'use --oracle name:address ...'; ``` ### Testing Considerations - [x] test(boot): fast-usdc core eval - needed chore: include noble USDC in orch integration test config - [x] test(boot): restart fastUSDC - [x] unit tests for config marshal ### Upgrade Considerations Restart is a pre-requisite for upgrade, so this is progress on testing upgrade of fastUSDC.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What is the Problem Being Solved?
In the course of delivering the first two milestones there are some aspects that weren't blockers for meeting the milestones (functioning in unit tests and swingset tests).
Description of the Design
At the point we're doing multi-chain integration tests, and before we do UI integration, these need to be resolved,
Security Considerations
Scaling Considerations
Test Plan
Upgrade Considerations
The text was updated successfully, but these errors were encountered: