-
Notifications
You must be signed in to change notification settings - Fork 212
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: permissionless AMM pools from Interchain assets #5397
Conversation
); | ||
kwNonce += 1; | ||
|
||
const liquidityIssuer = await E(amm).addPool( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Chris-Hibbert the addPool
call would move to step 2 when we require funds (#5377). I can't move it yet because the AMM requires the liquidity brand in the want when adding liquidity, even though it doesn't use it.
Maybe I should fix that in this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Chris-Hibbert the addPool call would move to step 2 when we require funds (#5377). I can't move it yet because the AMM requires the liquidity brand in the want when adding liquidity, even though it doesn't use it.
Maybe I should fix that in this PR?
Before and after #5377 the APIs for adding a pool are just different. Our choices are to reconcile in whichever PR is second, or merge this into #5377 once approved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did fix the odd AMM constraint and move addPool
to step 2. That way, when #5377 lands, we'll have the collateral on hand when we want to addPool
.
* }} pa | ||
* | ||
* @typedef {{ | ||
* minimumCentral: Amount<'nat'>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this should eventually be governed, let's at least add a comment to that effect here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a TODO to get this value dynamically from the AMM (once #5377 lands)
return deposited.then(_ => { | ||
seat.exit(); | ||
seat2.exit(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there should be a .catch()
clause here that returns the money from seat2 to seat1 and exits the seat.
I would test it by setting the AMM's minimum higher than the minimum enforced here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I plan to get the AMM's minimum on demand, so that test wouldn't last.
What is it that could throw? seat.exit()
or deposited
? In either case, what difference does it make which seat the money is returned in?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what difference does it make which seat the money is returned in?
I thought seat2 was purely internal, but I now see that I was wrong.
It still seems surprising that the caller has to check both seats to see if there's money there.
If someone has already saved an issuer on the AMM and called it 'Interchain5', then the saveIssuer()
call will fail, and the allocation will be stuck on seat2.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It still seems surprising that the caller has to check both seats to see if there's money there.
In discussion with @dtribble and co., we didn't see an obvious improvement. (There are 2 offers, so having 2 seats to check on failure never seemed odd, to me.)
If someone has already saved an issuer on the AMM and called it 'Interchain5', then the
saveIssuer()
call will fail
The saveIssuer()
call here doesn't depend on issuers in the AMM, as we discussed. (There could be a collision at addPool
, but that's before the saveIssuer()
here.)
8b3791b
to
2088c49
Compare
@Chris-Hibbert @turadg I wired up everything to get |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nothing stands out to me as a concern but given the security risks and my understanding of the interchain I don't feel comfortable approving and leave that to @Chris-Hibbert .
}); | ||
}; | ||
|
||
const keyword = denom; // ISSUE: should not show up in all wallets. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what does ISSUE
mean? something to do or just know about?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what does
ISSUE
mean?
um... something to do, I suppose.
In this case, it originated from discussion with @dtribble , who was OK postponing it; I didn't turn it into a separate issue, #5412 , until I got a chance to run it by @michaelfig , where we decided it's feasible in due course. Now that I have a number for it, I can add it to that comment.
receive: () => {}, | ||
}), | ||
}); | ||
// @ts-ignore mock doesn't have all the methods |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ts-expect-error
(not worth a push bc I plan to lint this soon)
return deposited.then(_ => { | ||
seat.exit(); | ||
seat2.exit(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what difference does it make which seat the money is returned in?
I thought seat2 was purely internal, but I now see that I was wrong.
It still seems surprising that the caller has to check both seats to see if there's money there.
If someone has already saved an issuer on the AMM and called it 'Interchain5', then the saveIssuer()
call will fail, and the allocation will be stuck on seat2.
update interchainPool tests switch minInitialPoolLiquidity back to Nat in startupAmm since it has to be driven from text values in environment variables.
* feat: make amm.addPool() require minimum collateral When creating a new pool for the AMM, there will be a minimum amount of IST. The caller is expected to provide an equivalent value of the collateral to balance the AMM pool. The liquidity tokens corresponding to that minimum will be added to the AssetReserve. If the caller adds more liquidity than the minimum, they get the extra liquidity tokens. Closes: #4643 This required updating a number of tests to initialize their AMMs with a minimal amount. * fix: don't create AMM pools in `addAssetToVault` * docs: update references to addPool in documentation * fix: update demoIssuers to use addPoolInvitation. * refactor: turn minInitialPoolLiquidity into an Amount * chore: cleanups. variable names and typescript annotations. * fix pool helper types * parameterize VirtualPool type * pool amounts are nat * chore: update TODO to include issue # * test: uncomment a test assertion before pool creation * refactor: integrate with #5397 update interchainPool tests switch minInitialPoolLiquidity back to Nat in startupAmm since it has to be driven from text values in environment variables. * chore: lint errors (unreferenced names) Co-authored-by: Turadg Aleahmad <turadg@agoric.com> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
refs: #5075, #4643
Description
Given sufficient IST, create an issuer for an IBC denom and an invitation to add a pool for it to the AMM.
There are 2 steps:
Un-ties knots discussed in #4643 (comment) , #5075 (comment)
TODO:
bankManager
should have a method likeaddAsset
that does not propagate to every wallet in the system.Security Considerations
Does not provide offer safety, due to usual propoerties of
offerTo
.Requires
bankManager
as a private arg.Documentation Considerations
Yet Another Contract to document / review.
cc @jessysaurusrex
Testing Considerations
Lightly tested. Reviewers will please suggest further tests.