27 implement config parameter management - #32
Conversation
…n with minting policy and design sketch
…ediction market documentation
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
…ment with enhanced market configuration and validator details Co-authored-by: Francisco Joray <franciscojoray@users.noreply.github.com>
…ettlement documentation
…h detailed market parameters and collateral handling
Co-authored-by: Francisco Joray <franciscojoray@users.noreply.github.com>
Co-authored-by: Francisco Joray <franciscojoray@users.noreply.github.com>
…nt-config-parameter-management
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
rober-m
left a comment
rober-m
left a comment
There was a problem hiding this comment.
Great work!! 😃 I like where this is going!
I left some comments, and I'll push a few small commits to address some of them, but this will need more work before merging. Some notes in general:
- We need to add the specs of the settings protocol.
- Vesting broke. I'll fix it in a stacked PR and leave it as-is here to avoid confusion.
- We have to add TS formatting rules or a hook to the repo to avoid formatting noise.
- We're not testing the case when the Datum has to have a specific shape in the e2e (
validate_datum != True) - I updated the compiler to v1.1.21, but I didn't re-generate the blueprints. We should re-generate them eventually, but leaving it up to you if you want to revert the compiler version for now.
- Tx3 is not capturing all cases (no withdrawal for auth and not generic datum)
The rest of the notes are in specific places. Thank you for your work!!
| type OptionalInt { | ||
| Some { | ||
| value: Int, | ||
| }, | ||
| None, | ||
| } |
There was a problem hiding this comment.
There's no Option<Data> type in Tx3? Should there be?
| current: Int, | ||
| next: OptionalInt, |
There was a problem hiding this comment.
Bug: Why are these Int and OptionalInt? These should be generic!
There was a problem hiding this comment.
Add a test for different shapes
| } | ||
|
|
||
| signers { | ||
| Applier, |
There was a problem hiding this comment.
How does this work for withdrawal scripts? Do we need to define all transactions twice (once for auth-by-signature and once for auth-by-withdrawal-script)?
There was a problem hiding this comment.
Yes, every transaction authorized by signature has a counterpart authorized by script.
There was a problem hiding this comment.
This seems very fragile and hacky. Not sure what to do about it, but I'm pretty sure it'll break soon
…rides in devnet-test script
No description provided.