@agoric/orchestration 0.1.1-dev-d756c83.0.d756c83 → 0.1.1-dev-e9efaa1.0.e9efaa1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,405 @@
1
+ /**
2
+ * @file General API of orchestration
3
+ * - must not have chain-specific types without runtime narrowing by chain id
4
+ * - should remain relatively stable.
5
+ */
6
+
7
+ // eslint-disable-next-line @typescript-eslint/no-unused-vars -- fails to notice the @see uses
8
+
9
+
10
+
11
+
12
+
13
+
14
+
15
+
16
+
17
+
18
+
19
+
20
+
21
+
22
+
23
+
24
+
25
+
26
+
27
+
28
+
29
+
30
+
31
+
32
+
33
+
34
+
35
+
36
+
37
+
38
+ /**
39
+ * Options relevant to all queries (non-mutating).
40
+ */
41
+
42
+
43
+
44
+
45
+ /**
46
+ * Options relevant to all actions (mutating).
47
+ */
48
+
49
+
50
+
51
+
52
+ /**
53
+ * A denom that designates a path to a token type on some blockchain.
54
+ *
55
+ * Multiple denoms may designate the same underlying base denom (e.g., `uist`,
56
+ * `uatom`) on different Chains or on the same Chain via different paths. On
57
+ * Cosmos chains, all but the base denom are IBC style denoms, but that may vary
58
+ * across other chains. All the denoms that designate the same underlying base
59
+ * denom form an equivalence class, along with the unique Brand on the local
60
+ * Chain. Some operations accept any member of the equivalence class to
61
+ * effectively designate the corresponding token type on the target chain.
62
+ */
63
+ // ibc/... or uist
64
+
65
+ // ??? when multiple Denoms provide paths to the same remote token type,
66
+ // should the brand be 1:1 with that equivalence class or each Denom?
67
+ /**
68
+ * In many cases, either a denom string or a local Brand can be used to
69
+ * designate a remote token type.
70
+ */
71
+
72
+
73
+ /**
74
+ * Count of some fungible token on some blockchain.
75
+ *
76
+ * @see {@link Orchestrator.asAmount} to convert to an Amount surjectively
77
+ */
78
+
79
+
80
+
81
+
82
+
83
+ /** Amounts can be provided as pure data using denoms or as ERTP Amounts */
84
+
85
+
86
+ /**
87
+ * Per `chain_id` in CAIP-2. In that spec all chain IDs are scoped
88
+ * (namespace:reference) but in the Cosmos ecosystem the namespace is implied
89
+ * and they use `chain_id`/`chainId` for what CAIP-2 calls the `reference`. We
90
+ * qualify the term here to avoid confusion.
91
+ *
92
+ * @see {@link https://chainagnostic.org/CAIPs/caip-2}
93
+ */
94
+
95
+
96
+ /**
97
+ * à la CAIP-10
98
+ *
99
+ * account_id: chain_id + ":" + account_address
100
+ * chain_id: [-a-z0-9]{3,8}:[-_a-zA-Z0-9]{1,32} (See [CAIP-2][])
101
+ * account_address: [-.%a-zA-Z0-9]{1,128}
102
+ *
103
+ * @see {@link https://chainagnostic.org/CAIPs/caip-10}
104
+ */
105
+
106
+
107
+ /**
108
+ * Specific to Cosmos chains
109
+ * @see {AccountId} for universal account identifier
110
+ */
111
+
112
+
113
+
114
+
115
+
116
+
117
+
118
+
119
+ /**
120
+ * Info used to identify blockchains across ecosystems
121
+ * @see {@link https://chainagnostic.org/CAIPs/caip-2}
122
+ */
123
+
124
+
125
+
126
+
127
+
128
+
129
+
130
+
131
+
132
+
133
+
134
+
135
+ /**
136
+ * Shape that `ChainHub` is expecting
137
+ */
138
+
139
+
140
+
141
+ /**
142
+ * A value that can be converted mechanically to an AccountId.
143
+ * @see {@link ChainHub.resolveAccountId}
144
+ */
145
+
146
+
147
+
148
+
149
+
150
+
151
+
152
+
153
+ /**
154
+ * Object that controls an account on a particular chain.
155
+ *
156
+ * The methods available depend on the chain and its capabilities.
157
+ */
158
+
159
+
160
+
161
+
162
+
163
+
164
+
165
+
166
+
167
+
168
+ /**
169
+ * An object for access the core functions of a remote chain.
170
+ *
171
+ * Note that "remote" can mean the local chain; it's just that
172
+ * accounts are treated as remote/arms length for consistency.
173
+ */
174
+
175
+
176
+
177
+
178
+
179
+
180
+
181
+
182
+
183
+
184
+
185
+
186
+
187
+
188
+
189
+
190
+
191
+
192
+
193
+
194
+
195
+
196
+
197
+
198
+
199
+
200
+
201
+ /**
202
+ * Used with `orch.getDenomInfo('ibc/1234')`. See {@link Orchestrator.getDenomInfo}
203
+ */
204
+
205
+
206
+
207
+
208
+
209
+
210
+
211
+
212
+
213
+
214
+
215
+
216
+
217
+
218
+ /**
219
+ * Provided in the callback to `orchestrate()`.
220
+ */
221
+
222
+
223
+
224
+
225
+
226
+
227
+
228
+
229
+
230
+
231
+
232
+
233
+
234
+
235
+
236
+
237
+
238
+
239
+
240
+
241
+
242
+
243
+
244
+
245
+
246
+
247
+
248
+
249
+
250
+
251
+
252
+
253
+
254
+
255
+
256
+ /**
257
+ * An object that supports high-level operations for an account on a remote chain.
258
+ */
259
+
260
+
261
+
262
+
263
+
264
+
265
+
266
+
267
+
268
+
269
+
270
+
271
+
272
+
273
+
274
+
275
+
276
+
277
+
278
+
279
+
280
+
281
+
282
+
283
+
284
+
285
+
286
+
287
+
288
+
289
+
290
+
291
+
292
+
293
+
294
+
295
+
296
+
297
+
298
+
299
+
300
+
301
+
302
+
303
+
304
+
305
+
306
+
307
+
308
+
309
+
310
+
311
+
312
+
313
+
314
+
315
+
316
+
317
+
318
+
319
+
320
+
321
+
322
+
323
+
324
+
325
+
326
+
327
+
328
+
329
+
330
+
331
+
332
+
333
+
334
+
335
+
336
+
337
+
338
+
339
+
340
+
341
+
342
+
343
+
344
+
345
+
346
+
347
+
348
+
349
+
350
+
351
+
352
+ /**
353
+ * Flows to orchestrate are regular Javascript functions but have some
354
+ * constraints to fulfill the requirements of resumability after termination of
355
+ * the enclosing vat. Some requirements for each orchestration flow:
356
+ * - must not close over any values that could change between invocations
357
+ * - must satisfy the `OrchestrationFlow` interface
358
+ * - must be hardened
359
+ * - must not use `E()` (eventual send)
360
+ *
361
+ * The call to `orchestrate` using a flow function in reincarnations of the vat
362
+ * must have the same `durableName` as before. To help enforce these
363
+ * constraints, we recommend:
364
+ *
365
+ * - keeping flows in a `.flows.js` module
366
+ * - importing them all with `import * as flows` to get a single object keyed by
367
+ * the export name
368
+ * - using `orchestrateAll` to treat each export name as the `durableName` of
369
+ * the flow
370
+ * - adopting `@agoric/eslint-config` that has rules to help detect problems
371
+ */
372
+
373
+
374
+
375
+
376
+ /**
377
+ * Internal structure for TransferMsgs.
378
+ * The type must be able to express transfers across different chains and transports.
379
+ *
380
+ * NOTE Expected to change, so consider an opaque structure.
381
+ * @internal
382
+ */
383
+
384
+
385
+
386
+
387
+
388
+
389
+
390
+ /** @alpha */
391
+
392
+
393
+
394
+
395
+ /** @alpha */
396
+
397
+
398
+
399
+
400
+ /** @alpha */
401
+
402
+
403
+
404
+
405
+
package/src/types.js ADDED
@@ -0,0 +1,27 @@
1
+ /** @file Rollup of all type definitions in the package, for local import and external export */
2
+
3
+
4
+
5
+
6
+
7
+
8
+
9
+
10
+
11
+
12
+
13
+
14
+
15
+
16
+
17
+
18
+
19
+
20
+ /**
21
+ * ({@link ZCF})-like tools for use in {@link OrchestrationFlow}s.
22
+ */
23
+
24
+
25
+
26
+
27
+
@@ -0,0 +1,13 @@
1
+
2
+
3
+ // Redefine abitype's TypedDataParameter to make it generic
4
+
5
+
6
+
7
+
8
+
9
+
10
+
11
+
12
+
13
+