feat(orchestration): icq balance query #9198

0xpatrickdev · 2024-04-05T04:44:22Z

Description

Binds an icqcontroller-* port and sends a query packet using CosmosQuery (/icq/v1/packet.js) and RequestQuery (/tendermint/abci/types.js).
Adds .queryBalance([denom]) method to StakingAccountHolder exo in StakeAtom contract, using QueryBalanceRequest (/cosmos/bank/v1beta1/query.js)
adds icq/v1 protos from cosmos/ibc-apps#8e64543
adds JsonSafe, typeUrlToGrpcPath, and toRequestQueryJson helpers to @agoric/cosmic-proto
ensures we are using ChainAddress objects in all orchestration code (types for chain addresses #9162)

Able to confirm port creation and successful balances queries in e2e testing:

relayer logs

2024-04-05T01:57:06.907563Z  INFO ThreadId(29) worker.batch{chain=agoriclocal}:supervisor.handle_batch{chain=agoriclocal}:supervisor.process_batch{chain=agoriclocal}:worker.channel{channel=channel::channel-0/icqcontroller-0:agoriclocal->osmosis-test}: 🎊  osmosis-test => OpenTryChannel(OpenTry { port_id: icqhost, channel_id: channel-1, connection_id: connection-1, counterparty_port_id: icqcontroller-0, counterparty_channel_id: channel-0 }) at height 0-470
2024-04-05T01:57:06.907586Z  INFO ThreadId(29) worker.batch{chain=agoriclocal}:supervisor.handle_batch{chain=agoriclocal}:supervisor.process_batch{chain=agoriclocal}:worker.channel{channel=channel::channel-0/icqcontroller-0:agoriclocal->osmosis-test}: channel handshake step completed with events: OpenTryChannel(OpenTry { port_id: icqhost, channel_id: channel-1, connection_id: connection-1, counterparty_port_id: icqcontroller-0, counterparty_channel_id: channel-0 })
2024-04-05T01:57:11.647420Z  INFO ThreadId(48) worker.batch{chain=osmosis-test}:supervisor.handle_batch{chain=osmosis-test}:supervisor.process_batch{chain=osmosis-test}:worker.channel{channel=channel::channel-1/icqhost:osmosis-test->agoriclocal}: 🎊  agoriclocal => OpenAckChannel(OpenAck { port_id: icqcontroller-0, channel_id: channel-0, connection_id: connection-0, counterparty_port_id: icqhost, counterparty_channel_id: channel-1 }) at height 0-52
2024-04-05T01:57:11.647448Z  INFO ThreadId(48) worker.batch{chain=osmosis-test}:supervisor.handle_batch{chain=osmosis-test}:supervisor.process_batch{chain=osmosis-test}:worker.channel{channel=channel::channel-1/icqhost:osmosis-test->agoriclocal}: channel handshake step completed with events: OpenAckChannel(OpenAck { port_id: icqcontroller-0, channel_id: channel-0, connection_id: connection-0, counterparty_port_id: icqhost, counterparty_channel_id: channel-1 })

Security Considerations

Scaling Considerations

Documentation Considerations

Testing Considerations

Upgrade Considerations

cloudflare-workers-and-pages · 2024-04-22T17:23:00Z

Deploying agoric-sdk with Cloudflare Pages

Latest commit:	`9f0ae09`
Status:	✅ Deploy successful!
Preview URL:	https://562db353.agoric-sdk.pages.dev
Branch Preview URL:	https://9072-icq-query.agoric-sdk.pages.dev

View logs

turadg · 2024-04-22T18:31:10Z

packages/orchestration/src/utils/packet.js

+/** @typedef {{ path: string; data: string; height?: bigint; prove?: boolean; }} QueryMsg like RequestQuery from Tendermint ABCI, but with a base64 encoded `data` key */
+/** @typedef {Omit<ResponseQuery, 'key'|'value'> & { key: string; value: string; }} QueryResponse like ResponseQuery from Tendermint ABCI, but with a base64 encoded `key` and `value` keys */


Let's try to hew closely to the external typedefs.

Suggested change

/** @typedef {{ path: string; data: string; height?: bigint; prove?: boolean; }} QueryMsg like RequestQuery from Tendermint ABCI, but with a base64 encoded `data` key */

/** @typedef {Omit<ResponseQuery, 'key'|'value'> & { key: string; value: string; }} QueryResponse like ResponseQuery from Tendermint ABCI, but with a base64 encoded `key` and `value` keys */

/** @typedef {RequestQuery & { data: string; }} QueryMsg like RequestQuery from Tendermint ABCI, but with a base64 encoded `data` key */

/** @typedef {ResponseQuery & { key: string; value: string; }} QueryResponse like ResponseQuery from Tendermint ABCI, but with a base64 encoded `key` and `value` keys */

That reveals an undocumented difference: this had made height and prove optional but they aren't in RequestQuery:

export interface RequestQuery { data: Uint8Array; path: string; height: bigint; prove: boolean; }

Future improvements:

a helper to generate a base64 type from interface

update the codegen to make that the return type instead of unknown

Here's a helper we could use,

// TODO make codegen toJSON() return these instead of unknown /** * Proto Any with arrays encoded as base64 */ export type Base64Any<T> = { [Prop in keyof T]: T[Prop] extends Uint8Array ? string : T[Prop]; };

I'll try to incorporate that into #9219

Done. I think we should try to land #9219 first

I pushed default values for height and prove out of this implementation, but we might consider including them in the future. The default values we get from .fromPartial() (height: 0n, prove: false) are documented in the tests.

I'm not sure if these defaults are sensible, but responses seem to be reactive to state changes despite the height: 0n parameter. Perhaps, this parameter is more intended for historical queries.

prove is something we may want to investigate more - the ~only mention in cosmos/ibc-apps/modules/async-icq is a failing test which leads me to believe query proofs may not yet be supported:
https://github.com/cosmos/ibc-apps/blob/18248c35e913b3ccba99a2756612b1fcb3370a0d/modules/async-icq/keeper/relay_test.go#L132-L154

dckc · 2024-04-22T19:28:14Z

packages/boot/test/bootstrapTests/test-vat-orchestration.ts

+  const orchestration = await EV.vat('bootstrap').consumeItem('orchestration');
+
+  const account = await EV(orchestration).createQueryConnection('connection-0');
+  t.log('Query Account', account);
+  t.truthy(account, 'createAccount returns an account');
+  t.truthy(
+    matches(account, M.remotable('QueryConnection')),
+    'QueryConnection is a remotable',
+  );


What is the role of the party making a connection?

This code suggests it's "As the BLD stakers, we can make query connections."
Is that the expected usage?

I suspect it's "As a contract (developer), I can make query connections."
I suggest expressing that as something like...

test('Query connection can be created', async t => { const contract1 = async ({ orchestration }) => { const account = await EV(orchestration).createQueryConnection('connection-0'); t.log('Query Account', account); t.truthy(account, 'createAccount returns an account'); t.truthy( matches(account, M.remotable('QueryConnection')), 'QueryConnection is a remotable', ); } // core eval context { const { runUtils } = t.context; const { EV } = runUtils; const orchestration = await EV.vat('bootstrap').consumeItem('orchestration'); await contract1({ orchestration }); } });

The change in stakingAccountHolder.js suggests that the contract isn't expected to get all of orchestration but rather only the connection (account? are these synonyms?):

{ const { runUtils } = t.context; const { EV } = runUtils; const orchestration = await EV.vat('bootstrap').consumeItem('orchestration'); const account = await EV(orchestration).createQueryConnection('connection-0'); t.log('Query Account', account); await contract1({ queryConnection: account }); }

Updated to use this convention

dckc · 2024-04-22T19:35:39Z

packages/orchestration/src/contracts/stakingAccountHolder.js

@@ -102,7 +138,7 @@ export const prepareStakingAccountHolder = (baggage, makeRecorderKit, zcf) => {
          // FIXME brand handling and amount scaling
          const amount = {
            amount: String(ertpAmount.value),
-            denom: 'uatom',
+            denom: this.state.baseDenom, // TODO use ertpAmount.brand


TODO when? Do we have an issue number? Or did you mean to do it in this PR?

dckc · 2024-04-22T19:38:28Z

packages/orchestration/src/contracts/stakingAccountHolder.js

@@ -4,14 +4,18 @@ import {
  MsgDelegate,
  MsgDelegateResponse,
 } from '@agoric/cosmic-proto/cosmos/staking/v1beta1/tx.js';
+import {


src/contracts suggests this contract is part of the product API. Is that the case? or is it an example?
It's a pattern we have come to regret in the zoe package: #7392

Maybe they belong in tools/?

Now in /src/examples after rebasing

dckc · 2024-04-22T19:41:09Z

packages/orchestration/src/guards.js

@@ -0,0 +1,7 @@
+import { M } from '@endo/patterns';


The conventional filename for this seems to be typeGuards.js:

$ find packages/ -name 'typeGuards.js' packages/smart-wallet/src/typeGuards.js packages/internal/src/typeGuards.js packages/time/src/typeGuards.js packages/zoe/src/typeGuards.js packages/SwingSet/src/typeGuards.js packages/governance/src/typeGuards.js packages/ERTP/src/typeGuards.js

dckc · 2024-04-22T19:42:45Z

packages/orchestration/src/orchestration.js

  zone.exoClassKit(
    'Orchestration',
    {
      self: M.interface('OrchestrationSelf', {
-        bindPort: M.callWhen().returns(M.remotable()),
+        bindPort: M.callWhen(M.record()).returns(M.remotable()),


if you meant that it can take a promise for a record, that needs M.await().
That would be unusual, though.

dckc · 2024-04-22T19:46:12Z

packages/orchestration/src/proposals/orchestration-proposal.js

@@ -92,6 +92,13 @@ export const getManifestForOrchestration = (_powers, { orchestrationRef }) => ({
        orchestrationVat: 'orchestration',
      },
    },
+
+    [addOrchestrationToClient.name]: {


I gather this is for use from the REPL.

Do we test it?

I'm surprised the homeKeys test hasn't failed.
https://github.com/Agoric/agoric-sdk/blob/master/packages/boot/test/bootstrapTests/test-demo-config.ts#L42

Another candidate is..

https://github.com/Agoric/agoric-sdk/blob/master/packages/solo/test/test-home.js

Thank you for the pointers, but I have removed this from the PR

dckc · 2024-04-22T19:48:27Z

packages/orchestration/src/queryConnection.js

+});
+
+/** @param {Zone} zone */
+export const prepareQueryConnection = zone =>


Suggested change

export const prepareQueryConnection = zone =>

export const prepareQueryConnectionKit = zone =>

dckc · 2024-04-22T19:49:46Z

packages/orchestration/src/utils/address.js

+ */
+export const makeICQChannelAddress = (
+  controllerConnectionId,
+  { version = 'icq-1' } = {},


is it OK for version to be any string at all, including those containing /?
If so, I'd appreciate a test to say so explicitly.

Good callout. I've added44adcf1 which documents the limited functionality better. This function will not be exposed to API consumers, so I didn't feel it necessary to validate version. As I'm writing this comment it feels like a good idea to add the @internal typedoc annotation.

Doing some additional testing, it seems like network / ibc do not throw if we provide an invalid remoteAddr to .connect(). Is this worth implementing? Looks like decodeRemoteIbcAddress, or at least the part that throws a TypeError, used in the onConnect handler could be leveraged in connect cc @michaelfig

I would support adding code to do a throw if it's an "invalid remoteAddr", but the layering must be correct.

Only the ibc implementation (not network) should have that knowledge. Support for other transports like Wormhole or Hyperlane may be required down the road, and their notion of an "invalid remoteAddr" will necessarily be different from IBC's.

Ok cool. Attempted this here:e1aac9c, please lmk what you think.

I was thinking to make ProtocolHandler['validateRemoteAddr'] optional, but wasn't sure the best way to verify the existence of a remote method (i.e. if (protocolHandler.validateRemoteAddr) protocolHandler.validateRemoteAddr())

Edit: removed in e928643, as this breaks the ping pong between ibcServerMock and ibcClientMock in test-net-ibc-upgrade.ts. Cost to update this test seems high from my POV.

... wasn't sure the best way to verify the existence of a remote method

The only way is to try it.

The only way is to try it.
Yes, and if you see how rethrowUnlessMissing is used as a catch handler, that will interpret the rejection and if it seems to be due to a missing method, it will swallow the error, otherwise will throw it again.

rethrowUnlessMissing - nice! was going to say it'd be handy to have a function/tool for this

turadg · 2024-04-22T19:37:38Z

packages/orchestration/src/utils/packet.js

+/** @typedef {{ path: string; data: string; height?: bigint; prove?: boolean; }} QueryMsg like RequestQuery from Tendermint ABCI, but with a base64 encoded `data` key */
+/** @typedef {Omit<ResponseQuery, 'key'|'value'> & { key: string; value: string; }} QueryResponse like ResponseQuery from Tendermint ABCI, but with a base64 encoded `key` and `value` keys */


Done. I think we should try to land #9219 first

packages/boot/test/bootstrapTests/test-vat-orchestration.ts

turadg · 2024-04-22T19:47:09Z

packages/boot/test/bootstrapTests/test-vat-orchestration.ts

+  t.truthy(typeof result.height === 'bigint');
+  t.truthy(
+    result.value.length === 0,
+    'XXX why do we get an empty Uint8Array here?',


is this just XXX or do we need to resolve it before merge?

I am not sure what the expected behavior should be here. It doesn't seem we need this field, but it's surprising to see it provided in the response.

I have removed this assertion for now

packages/orchestration/src/contracts/stakingAccountHolder.js

turadg · 2024-04-22T19:52:26Z

packages/orchestration/src/contracts/stakingAccountHolder.js

+              data: QueryBalanceRequest.encode(
+                QueryBalanceRequest.fromPartial({
+                  address: chainAddress,
+                  denom: denom || this.state.baseDenom,


default params belong in the function signature

turadg · 2024-04-22T19:53:40Z

packages/orchestration/src/contracts/stakingAccountHolder.js

+            decodeBase64(result.key),
+          );
+          if (!balance) throw Fail`Error parsing result ${result}`;
+          // TODO, return Amount? cast amount to bigint?


worth a ticket to ensure we come back to this. maybe there is one already

turadg · 2024-04-22T19:53:48Z

packages/orchestration/src/contracts/stakingAccountHolder.js

@@ -102,7 +138,7 @@ export const prepareStakingAccountHolder = (baggage, makeRecorderKit, zcf) => {
          // FIXME brand handling and amount scaling
          const amount = {
            amount: String(ertpAmount.value),
-            denom: 'uatom',
+            denom: this.state.baseDenom, // TODO use ertpAmount.brand


ditto, ticket

turadg · 2024-04-22T19:55:24Z

packages/orchestration/src/orchestration.js

          );
-          this.state.icaControllerNonce += 1;
+          this.state[opts.nonceKey] += 1;


should this be before the remote call? the remote might throw with partial failure and a subsequent request would use the same value. cc @iomekam

_I am going to rebase this PR on top of #9228 once ready, so please disregard this logic. _

Was not thinking of the partial failure case, although it seems harmless as the object containing Port is not returned to the user until the Port + Connection are successfully instantiated. Nonetheless, this seems like it wouldn't comply with the Checks Effects Interactions pattern and it's better to make the state update before the remote call.

turadg · 2024-05-02T22:35:38Z

packages/cosmic-proto/package.json

@@ -52,6 +56,14 @@
      "types": "./dist/codegen/ibc/*.d.ts",
      "default": "./dist/codegen/ibc/*.js"
    },
+    "./icq/v1/*.js": {


/v1 unnecessary, please remove

turadg · 2024-05-02T22:36:01Z

packages/cosmic-proto/package.json

@@ -64,6 +76,14 @@
      "types": "./dist/codegen/agoric/swingset/swingset.d.ts",
      "default": "./dist/codegen/agoric/swingset/swingset.js"
    },
+    "./tendermint/abci/*.js": {


/abci unnecessary, please remove

turadg · 2024-05-02T22:38:00Z

packages/orchestration/src/exos/icqConnectionKit.js

+     */
+    port =>
+      /**
+       * @type {{


consider naming this type State

turadg · 2024-05-02T22:39:09Z

packages/orchestration/src/exos/stakingAccountKit.js

 * @import { RecorderKit, MakeRecorderKit } from '@agoric/zoe/src/contractSupport/recorder.js';
 * @import { Baggage } from '@agoric/swingset-liveslots';
- * @import {AnyJson} from '@agoric/cosmic-proto';
+ * @import { AnyJson, RequestQueryJson } from '@agoric/cosmic-proto';


no padding for types lists, only for object properties

Suggested change

* @import { AnyJson, RequestQueryJson } from '@agoric/cosmic-proto';

* @import {AnyJson, RequestQueryJson} from '@agoric/cosmic-proto';

Acknowledged, updated one of the files I touched during other feedback and will prefer this going forward

turadg · 2024-05-02T22:42:35Z

packages/orchestration/src/service.js

  zone.exoClassKit(
    'Orchestration',
    {
      self: M.interface('OrchestrationSelf', {
-        bindPort: M.callWhen().returns(M.remotable()),
+        allocateICAControllerPort: M.callWhen().returns(
+          NetworkShape.Vow$(NetworkShape.Port),


what is this Vow$ thing?

Sourced from here:

agoric-sdk/packages/network/src/network.js

Line 676 in 160d332

bindPort: M.callWhen(Shape.Endpoint).returns(Shape.Vow$(Shape.Port)),

turadg · 2024-05-02T22:44:53Z

packages/orchestration/src/utils/packet.js

+  ).finish();
+
+  return JSON.stringify({
+    type: 1,


magic number. please import or name it with a const

Referencing InterchainPacketData and the Type.TYPE_EXECUTE_TX enum now: cb1a005

dckc · 2024-05-03T00:25:03Z

packages/orchestration/src/utils/packet.js

+    /** @type {Base64Any<InterchainAccountPacketData>} */ ({
+      type: PacketType.TYPE_EXECUTE_TX,


packages/orchestration/src/utils/address.js

0xpatrickdev · 2024-05-03T14:59:15Z

@turadg I added caaec18 since your last review so we don't have to manually type gRPC paths (and can derive them from typeUrls)

P.S. seems like something we could upstream to @cosmology/telescope. Would expect to see something ~like:

type QueryBalanceRequest = {
  grpcPath: string;
  toRequestQuery: (req: QueryBalanceRequest) => { path: string, data: Uint8Array };
}

to complement the existing typeUrl property and toProtoMsg method.

0xpatrickdev · 2024-05-03T15:32:05Z

packages/cosmic-proto/proto/icq/v1/icq.proto

@@ -0,0 +1,15 @@
+syntax = "proto3";
+
+package icq.v1;


It's unclear to me whether these (icq/v1) should live here (top level) or inside /ibc/applications. When placed in that directory, i see Error: Dependency Not Found icq/v1/icq.proto during yarn codegen. A concern is that the correct typeUrls may not be generated with this folder structure. Its seems we'd need to update this line to package ibc.applications.icq.v1, but not sure there is any sort of precedent for editing these files.

cc @michaelfig for insights

The naming for .proto files is relative to the most immediate proto/ directory. It is important not to change the package ... lines to match a different directory structure. That will break the generated proto codecs. Instead just move the files into proto/${packageName.replaceAll('.', '/'), as was correctly done in this PR.

0xpatrickdev · 2024-05-03T15:35:23Z

packages/orchestration/src/service.js

+            return this.state.icqConnections.get(controllerConnectionId)
+              .connection;
+          }
+          // allocate a new Port for every Connection


I am not sure if this is the correct behavior. An alternative is to bind a single icqcontroller-* port during the orchestration-proposal.js. Happy to fix here, or create a small task to capture the work.

seems worth its own issue; something like:

optimize ICQ port allocation

There I'd like us to find an ICQ spec that tells us what the right answer is, and/or do some integration testing.

Created #9317 and included it as a code comment

dckc · 2024-05-03T15:57:20Z

packages/orchestration/src/exos/icqConnectionKit.js

+ * }} ICQConnectionKitState
+ */
+
+/** @param {Zone} zone */


I'd appreciate a more full docstring here.

In particular, let's please cite any external design constraints, such as the ICQ spec that we're conforming to.

✅ bd88224

turadg · 2024-05-03T18:30:41Z

packages/cosmic-proto/src/helpers.ts

+ */
+export type RequestQueryJson = JsonSafe<RequestQuery>;
+
+const QUERY_REQ_TYPEURL_RE = /^\/(\w+(?:\.\w+)*)\.Query(\w+)Request$/;


I don't really get the motivation for this but I'm not opposed.

Consider using named capture groups tho.

Motivation for the validation inside the function, or the function itself?

…AChannelAddress

- sourced from: https://github.com/cosmos/ibc-apps/tree/18248c35e913b3ccba99a2756612b1fcb3370a0d/modules/async-icq/proto/icq/v1 - refs: #9072

- refs: #9072

- throws TypeError if string does not match REMOTE_ADDR_RE - not currently used as a runtime check in the ibc ProtocolImpl, but could be if [test-net-ibc-upgrade.ts](packages/boot/test/bootstrapTests/test-net-ibc-upgrade.ts) is amenable

- refs: #9072

0xpatrickdev force-pushed the 8881-ica-send-message branch 5 times, most recently from 38c7bc3 to 54d830f Compare April 9, 2024 17:50

Base automatically changed from 8881-ica-send-message to master April 9, 2024 18:46

0xpatrickdev force-pushed the 9072-icq-query branch 2 times, most recently from 1ecce05 to ce019fa Compare April 10, 2024 18:14

0xpatrickdev force-pushed the 9072-icq-query branch from ce019fa to 1ffc1be Compare April 22, 2024 17:22

0xpatrickdev marked this pull request as ready for review April 22, 2024 17:28

0xpatrickdev requested review from turadg, dckc and michaelfig April 22, 2024 17:28

turadg reviewed Apr 22, 2024

View reviewed changes

dckc reviewed Apr 22, 2024

View reviewed changes

turadg reviewed Apr 22, 2024

View reviewed changes

This was referenced Apr 24, 2024

Move port allocation in network vat to PortAllocator #9228

Merged

9207 orchestrator stub #9208

Merged

0xpatrickdev force-pushed the 9072-icq-query branch 4 times, most recently from 2347cca to e36559e Compare April 25, 2024 01:50

turadg reviewed May 2, 2024

View reviewed changes

dckc reviewed May 3, 2024

View reviewed changes

0xpatrickdev commented May 3, 2024

View reviewed changes

packages/orchestration/src/utils/address.js Show resolved Hide resolved

0xpatrickdev requested review from dckc and turadg May 3, 2024 00:34

turadg approved these changes May 3, 2024

View reviewed changes

0xpatrickdev force-pushed the 9072-icq-query branch from e78c7ad to 06d745e Compare May 3, 2024 14:50

0xpatrickdev commented May 3, 2024

View reviewed changes

dckc reviewed May 3, 2024

View reviewed changes

0xpatrickdev mentioned this pull request May 3, 2024

optimize ICQ port allocation #9317

Closed

turadg reviewed May 3, 2024

View reviewed changes

0xpatrickdev force-pushed the 9072-icq-query branch from bd88224 to 4f4c17f Compare May 3, 2024 19:59

0xpatrickdev added the automerge:rebase Automatically rebase updates, then merge label May 3, 2024

0xpatrickdev added 10 commits May 3, 2024 17:08

refactor(orchestration): rename makeICAConnectionAddress -> `makeIC…

d352775

…AChannelAddress

refactor(orchestration): rename parseAddress -> findAddressField

7817986

refactor(orchestration): rename parsePacketAck -> parseTxPacket

8d61c3f

feat(cosmic-proto): add icq/v1 proto + codegen for @agoric/orchestration

910e038

- sourced from: https://github.com/cosmos/ibc-apps/tree/18248c35e913b3ccba99a2756612b1fcb3370a0d/modules/async-icq/proto/icq/v1 - refs: #9072

feat(network): add allocateICQControllerPort to PortAllocator

b819aa9

- refs: #9072

feat(cosmic-proto): add JsonSafe and RequestQueryJson types

fe9dab4

- refs: #9072

feat(cosmic-proto): add toRequestQueryJson and typeUrlToGrpcPath

ea8e6d3

feat(orchestration): add support for queries (icq/v1)

79b5d0f

feat(orchestration): stakeAtom query balance

9f0ae09

0xpatrickdev force-pushed the 9072-icq-query branch from 4f4c17f to 9f0ae09 Compare May 3, 2024 21:08

mergify bot merged commit 8e94b2a into master May 6, 2024
63 checks passed

mergify bot deleted the 9072-icq-query branch May 6, 2024 04:40

0xpatrickdev mentioned this pull request May 13, 2024

orchestration: query chains that do not have async-icq enabled #9326

Open

Jorge-Lopes mentioned this pull request May 23, 2024

Orchestration API: add support for NFTs Jorge-Lopes/agoric-sdk#33

Open

7 tasks

		/** @typedef {{ path: string; data: string; height?: bigint; prove?: boolean; }} QueryMsg like RequestQuery from Tendermint ABCI, but with a base64 encoded `data` key */
		/** @typedef {Omit<ResponseQuery, 'key'\|'value'> & { key: string; value: string; }} QueryResponse like ResponseQuery from Tendermint ABCI, but with a base64 encoded `key` and `value` keys */

	export const prepareQueryConnection = zone =>
	export const prepareQueryConnectionKit = zone =>

	* @import { AnyJson, RequestQueryJson } from '@agoric/cosmic-proto';
	* @import {AnyJson, RequestQueryJson} from '@agoric/cosmic-proto';

		/** @type {Base64Any<InterchainAccountPacketData>} */ ({
		type: PacketType.TYPE_EXECUTE_TX,

feat(orchestration): icq balance query #9198

feat(orchestration): icq balance query #9198

Conversation

0xpatrickdev commented Apr 5, 2024 • edited Loading

Description

Security Considerations

Scaling Considerations

Documentation Considerations

Testing Considerations

Upgrade Considerations

cloudflare-workers-and-pages bot commented Apr 22, 2024 • edited Loading

Deploying agoric-sdk with Cloudflare Pages

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

0xpatrickdev Apr 24, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

0xpatrickdev Apr 24, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

0xpatrickdev May 3, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

0xpatrickdev commented May 3, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

0xpatrickdev May 3, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

0xpatrickdev commented Apr 5, 2024 •

edited

Loading

cloudflare-workers-and-pages bot commented Apr 22, 2024 •

edited

Loading

0xpatrickdev Apr 24, 2024 •

edited

Loading

0xpatrickdev Apr 24, 2024 •

edited

Loading

0xpatrickdev May 3, 2024 •

edited

Loading

0xpatrickdev commented May 3, 2024 •

edited

Loading

0xpatrickdev May 3, 2024 •

edited

Loading