You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* 1. Upgrade provisionPool. This upgrade overrides provisionWalletBridgerManager with a durable one
* 2. Add a new account and successfully provision it
* - Observe new account's address under `published.wallet.${address}`
* 3. Send some USDC_axl to provisionPoolAddress and observe its IST balances increases accordingly
* 4. Introduce a new asset to the chain and start a PSM instance for the new asset
* 4a. Deposit some of that asset to provisionPoolAddress
* 4b. Observe provisionPoolAddress' IST balance increase by the amount deposited in step 4a
* 5. Perform a null upgrade for provisionPool. This upgrade does NOT override provisionWalletBridgerManager
* - The goal here is to allow testing the bridgeHandler from the first upgrade is in fact durable
* 6. Auto provision
* 6a. Introduce a new account
* 6b. Fund it with IST and ATOM to be able to open a vault
* 6c. Try to open a vault WITHOUT provisioning the newly introduced account
* 6d. Observe the new account's address under `published.wallet`
* 7. Same as step 2. Checks manual provision works after null upgrade
*/
Security Considerations
Not significant.
Scaling Considerations
Since provisionPool and vat-bank introduces users to the SwingSet realm, it's significant in terms of scaling applications running on top Agoric chain.
Test Plan
Features to test
a3p local net
Test Net (Emerynet, XNet..)
Form
Manual Provision
yes
yes
agd (consider faucet as well)
Auto Provision
yes
yes
agd (open a new vault without provisioning)
Recovery of subscribed assets
yes
yes
observe from logs
Recovery of asset purses
yes
yes
observe from logs
Successful PSM swap (existing)
yes
yes
check PP address' balances
Successful PSM swap (new)
yes
NO
check PP address' balances
Gov params should survive
yes
yes
check vstorage
Upgrade Considerations
Important to make sure we upgrade v14-bank and v28-provisionPool together. The order shouldn't matter.
The text was updated successfully, but these errors were encountered:
As I said there, we should add some details about what to verify when the changes get to mainNet. I expect the latter to often just be "check for the following log message as evidence that the upgrade took place", but if there are behavioral changes, we may want to look for those as well, if there's a non-invasive way to be sure.
What is the Problem Being Solved?
We need to test provisionPool and bank keep working after an upgrade in Emerynet and any other test networks that are required.
Description of the Design
What's currently being tested in
a3p
?The
a3p
tests for upgradingv28-provisionPool
andv14-bank
focus on verifying the issue below:makeBridgeProvisionTool
from aFar
to anExo
#10425a3p
tests achieve these verifications by carrying out the steps below;agoric-sdk/a3p-integration/proposals/p:upgrade-19/provisionPool.test.js
Lines 8 to 24 in 340ef0d
Security Considerations
Not significant.
Scaling Considerations
Since
provisionPool
andvat-bank
introduces users to the SwingSet realm, it's significant in terms of scaling applications running on top Agoric chain.Test Plan
a3p
local netagd
(consider faucet as well)
agd
(open a new vault without provisioning)
Upgrade Considerations
Important to make sure we upgrade
v14-bank
andv28-provisionPool
together. The order shouldn't matter.The text was updated successfully, but these errors were encountered: