accounting around BankManager.addAsset #10067
-
BankManager.addAsset takes either a mint or a payment. In the payment case, what happens when the payment runs out? @michaelfig do you know? IOU a more clear question cc @tgrecojs |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
example from discussion in office hours today: import { E } from '@endo/far';
/**
* @typedef {{
* installation: PromiseSpaceOf<{ Meals: Installation }>;
* instance: PromiseSpaceOf<{ Breakfast: Instance }>;
* brand: PromiseSpaceOf<{ CornFlakes: Brand }>;
* issuer: PromiseSpaceOf<{ CornFlakes: Issuer }>;
* }} MyContractPowers
*/
/**
* @param {BootstrapPowers & MyContractPowers} permittedPowers
*/
export const deployMyThing = async permittedPowers => {
const {
consume: { zoe, bankManager },
installation: {
consume: { Meals },
},
instance: {
produce: { Breakfast },
},
brand: {
produce: { CornFlakes: CornflakesBrandProduce },
},
issuer: {
produce: { CornFlakes: CornflakesIssuerProduce },
},
} = permittedPowers;
await null;
/** @type {StartedInstanceKit<any>} */
const started = await E(zoe).startInstance(await Meals);
Breakfast.resolve(started.instance);
/** @type {StandardTerms} */
const terms = await E(zoe).getTerms(started.instance);
const {
brands: { CornFlakes: CornflakesBrand },
issuers: { CornFlakes: CornflakesIssuer },
} = terms;
// this does E(E(agoricNamesAdmin).lookupAdmin('brand')).update('Cornflakes', CornflakesBrand)
// which also updates the vstorage key published.agoricNames.brand
CornflakesBrandProduce.resolve(CornflakesBrand);
CornflakesIssuerProduce.resolve(CornflakesIssuer);
const payment = await E(started.creatorFacet).mintLotsOfCereal();
await E(bankManager).addAsset(
'ibc/lskdfjlsdjkf',
'Cornflakes',
'yummy Cornflakes',
{ brand: CornflakesBrand, issuer: CornflakesIssuer, payment},
);
}; |
Beta Was this translation helpful? Give feedback.
-
An ERTP mint means that JS controls the supply of the bridged token. A payment means that JS does not control the supply, and Cosmos believed that JS "grabbed" that payment's value from its supply at some time in the past. In both cases, an ERTP purse is created to represent the current value of Cosmos tokens that are held in escrow (but not withdrawn) from the bank purses. For every withdrawal from a bank purse, more Cosmos tokens are "grabbed" from a user bank account, escrowed on the Cosmos side, and transferred from the ERTP escrow purse to a fresh payment. For deposits to a bank purse, the ERTP assets are escrowed, Cosmos tokens are "given", and put into a user bank account on the Cosmos side. If the escrowed assets and circulating assets on one side of the bridge does not total the same as on the other side, there will be a conservation problem. This would potentially run out of assets to back withdrawals from bank purses or Cosmos bank accounts. |
Beta Was this translation helpful? Give feedback.
An ERTP mint means that JS controls the supply of the bridged token. A payment means that JS does not control the supply, and Cosmos believed that JS "grabbed" that payment's value from its supply at some time in the past. In both cases, an ERTP purse is created to represent the current value of Cosmos tokens that are held in escrow (but not withdrawn) from the bank purses.
For every withdrawal from a bank purse, more Cosmos tokens are "grabbed" from a user bank account, escrowed on the Cosmos side, and transferred from the ERTP escrow purse to a fresh payment…