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
docs: re-verify the client-library page at wharfkit antelope 1.2.0 (#18)
The page pinned 1.1.1 while 1.2.0 is the published release the platform installs, and its own text demands a re-check on upgrade. The 1.1.1 to 1.2.0 source diff is confined to send_transaction2 exception handling, so every fact holds and only the pin moves.
Copy file name to clipboardExpand all lines: AGENTS.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -64,6 +64,6 @@ Read the routed file in full rather than searching it. The facts there encode be
64
64
65
65
Take each section at face value and do not extrapolate past what it states. A page says what was checked, and what it does not say was not checked. `reference/validation.md` records how every page was validated and against what. It grades `reference/` and `guides/` only: a tutorial's claim is that its steps run, and a concepts page restates facts the pages it links already carry, so neither takes a row there.
66
66
67
-
Re-check any fact that names a version when that dependency moves. The two SDK pages are pinned to `@atomichub/atomicassets` 2.1.1, read at tag `v2.1.1`, and `@atomichub/atomicmarket` 2.4.1, read at tag `v2.4.1`; the client-library page is pinned to `@wharfkit/antelope` 1.1.1, and the AtomicAssets and AtomicMarket contract pages to `v2.0.0` and `v2.0.0`. A fact read at one of those pins is a fact about that release, not about the package name.
67
+
Re-check any fact that names a version when that dependency moves. The two SDK pages are pinned to `@atomichub/atomicassets` 2.1.1, read at tag `v2.1.1`, and `@atomichub/atomicmarket` 2.4.1, read at tag `v2.4.1`; the client-library page is pinned to `@wharfkit/antelope` 1.2.0, and the AtomicAssets and AtomicMarket contract pages to `v2.0.0` and `v2.0.0`. A fact read at one of those pins is a fact about that release, not about the package name.
68
68
69
69
Two skills sit beside these pages. `skills/atomic-integration/SKILL.md` carries the procedures a routing table cannot: the mint flow, the market composers, and the network choice. `skills/report/SKILL.md` writes a difficulty report when a page here turned out wrong, missing, or misleading, in the field shape this repository's issue forms accept.
Copy file name to clipboardExpand all lines: CHANGELOG.md
+6Lines changed: 6 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,6 +2,12 @@
2
2
3
3
What each release of this corpus changed, one release per tag. `Corrected` comes first in every release, because a fact that was wrong is what a returning reader has to see before anything else. The other sections are `Added`, `Revalidated`, and `Removed`, in that order, and a section with nothing in it is left out.
4
4
5
+
## 2026.08.2
6
+
7
+
### Revalidated
8
+
9
+
-`reference/wharfkit.md` reads at `@wharfkit/antelope` 1.2.0: the only source change since 1.1.1 is `send_transaction2` exception handling, and every fact on the page holds unchanged.
Copy file name to clipboardExpand all lines: reference/validation.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,7 +16,7 @@ This log traces how every fact in `reference/` and `guides/` was checked before
16
16
-`atomictools-contract` at commit `d89ce79e4` (the upstream repository has no release tag; the deployed `atomictoolsx` ABI on WAX matches this commit exactly)
17
17
-`atomicassets-sdk` at tag `v2.1.1`, commit `5c70c62` (published as `@atomichub/atomicassets` 2.1.1)
18
18
-`atomicmarket-sdk` at tag `v2.4.1`, commit `437300b` (published as `@atomichub/atomicmarket` 2.4.1)
19
-
-`@wharfkit/antelope` at `1.1.1`
19
+
-`@wharfkit/antelope` at `1.2.0`
20
20
-`@wharfkit/session` at `1.6.1`, with `@wharfkit/common` at `1.5.0` and `@wharfkit/wallet-plugin-privatekey` at `1.1.0`
21
21
-`@atomichub/vert` at `2.2.0`, commit `a8a4160`
22
22
-`AntelopeIO/leap` at `v5.0.3` (chain RAM billing: the billable-size constants and the call sites that charge them)
@@ -56,7 +56,7 @@ WAX mainnet still runs the V1 `atomicassets` and `atomicmarket` contracts (confi
56
56
|`reference/atomicmarket/v2-changes.md`|`atomicmarket-contract` (v2.0.0): `src/atomicmarket.cpp`| source-read | The defensive-guards section has an explicit `Source:` line. The "large integers serialize as strings" section describes live nodeos JSON-serialization behavior and carries no dedicated citation in this page; it is consistent with, and narrower than, the live-chain uint64 facts in `guides/querying-the-api.md`. |
57
57
|`reference/chain.md`| Live `nodeos`/WAX RPC behavior (`/v1/chain/get_account`); nodeos `chain_plugin.cpp` referenced for the error-message format | live-chain | No dedicated `Source:` line in this page. The error code and HTTP behavior are a live-RPC fact; the page also names the nodeos source file that emits the message text, which is not independently re-verified here. |
58
58
|`reference/contract-releases.md`|`atomicassets-contract` / `atomicmarket-contract`: `Makefile`, `scripts/patch-abi.py`, CI release workflow | source-read | No dedicated `Source:` line and no version pin in this page's frontmatter (build tooling applies across releases, not to one tag). Resource-usage figures (NET/CPU for `setcode`) read as measured observations rather than a cited source or a live probe; treat those magnitudes as approximate. |
59
-
|`reference/wharfkit.md`|`@wharfkit/antelope` client library source, pinned to `1.1.1`| source-read | No dedicated `Source:` line; each fact names the library behavior and, for one, an `@attention` note in the library's own source. Re-check on any `@wharfkit/antelope` upgrade, as the page itself states. |
59
+
|`reference/wharfkit.md`|`@wharfkit/antelope` client library source, pinned to `1.2.0`| source-read | No dedicated `Source:` line; each fact names the library behavior and, for one, an `@attention` note in the library's own source. Re-verified across the 1.1.1 to 1.2.0 diff: the only source change is send_transaction2 exception handling, which touches none of this page's facts. Re-check on any `@wharfkit/antelope` upgrade, as the page itself states. |
60
60
|`guides/asset-lifecycle.md`|`atomicassets-contract` (v2.0.0): `src/atomicassets.cpp`, `include/atomicassets.hpp`; `atomicassets-sdk` (`v2.1.1`, `5c70c62`): `src/Actions/Generator.ts`| source-read | Creator-flow walkthrough; every step cites the underlying action's source range. The SDK mint example and the numeric-guard note are source-read from the 2.1.1 builder, not executed: the guarded fields, the `-1` sentinel, and the single-object return shape are read from `Generator.ts` by line. |
61
61
|`guides/auctions.md`|`atomicmarket-contract` (v2.0.0): `src/atomicmarket.cpp`; `atomicmarket-sdk` (`v2.4.1`, `437300b`): `src/Actions/Generator.ts`; live `get_table_rows` curl example against `wax.greymass.com`| both | Lifecycle steps cite contract source; one section shows a live `get_table_rows` curl call to illustrate reading auction state. The composer section is source-read from the 2.4.1 builder: the announce-then-transfer order, the `auction` memo literal, and the `duration` uint32 check are read by line. |
62
62
|`guides/buyoffers.md`|`atomicmarket-contract` (v2.0.0): `src/atomicmarket.cpp`; `atomicmarket-sdk` (`v2.4.1`, `437300b`): `src/Actions/Generator.ts`| source-read | Every action (create, accept, decline, cancel, template variants) cites its source range. The two composer sections are source-read from the 2.4.1 builder: that `acceptbuyo` and `fulfilltbuyo` have no standalone builder method, the emitted order and memo literals, and the `allow_v1_bundle_buyoffer` throw are read by line. |
Copy file name to clipboardExpand all lines: reference/wharfkit.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,13 +1,13 @@
1
1
---
2
-
scope: "@wharfkit/antelope client library behavior for table reads, authority checks, and payer unwrapping, each verified against version 1.1.1 of the package"
2
+
scope: "@wharfkit/antelope client library behavior for table reads, authority checks, and payer unwrapping, each verified against version 1.2.0 of the package"
3
3
depends-on: []
4
4
key-modules:
5
5
- "@wharfkit/antelope"
6
6
---
7
7
8
8
# @wharfkit/antelope client behavior
9
9
10
-
Version-pinned facts below were verified against 1.1.1; re-check them on upgrade.
10
+
Version-pinned facts below were verified against 1.2.0; re-check them on upgrade.
11
11
12
12
## Typed get_table_rows is not a drop-in for dynamic reads
13
13
@@ -32,8 +32,8 @@ Typed endpoints such as `get_account` also strict-decode responses into structs,
32
32
33
33
## hasPermission does not recurse into account weights
34
34
35
-
`Authority.hasPermission` in @wharfkit/antelope (verified in 1.1.1) checks a public key only against the authority's direct `keys[]` entries; its own source carries an `@attention` note that indirect permissions via `accounts[]` weights are not considered. This matters on WAX: Cloud Wallet `.wam` accounts commonly delegate their active permission to a managing account (e.g. `managed.wax`), so verifying a recovered key with `hasPermission` alone rejects every such account. Off-chain verifiers need a recursive authority walk: fetch the account, accumulate weight from direct key matches, then recurse into each `accounts[]` entry and add its weight when the child authorizes the key, short-circuiting once the threshold is met. Bound the walk with a small depth cap (real delegations rarely exceed depth 2) and cycle detection keyed on (account, permission), removing the visited entry when a branch unwinds, or sibling branches that legitimately converge on the same downstream account are wrongly counted as zero weight. Also walk a permission's parent (e.g. `owner` for `active`) on the same account, since the chain accepts a parent-permission key wherever the child would suffice. Re-verify the no-recursion behavior on any library upgrade.
35
+
`Authority.hasPermission` in @wharfkit/antelope (verified in 1.2.0) checks a public key only against the authority's direct `keys[]` entries; its own source carries an `@attention` note that indirect permissions via `accounts[]` weights are not considered. This matters on WAX: Cloud Wallet `.wam` accounts commonly delegate their active permission to a managing account (e.g. `managed.wax`), so verifying a recovered key with `hasPermission` alone rejects every such account. Off-chain verifiers need a recursive authority walk: fetch the account, accumulate weight from direct key matches, then recurse into each `accounts[]` entry and add its weight when the child authorizes the key, short-circuiting once the threshold is met. Bound the walk with a small depth cap (real delegations rarely exceed depth 2) and cycle detection keyed on (account, permission), removing the visited entry when a branch unwinds, or sibling branches that legitimately converge on the same downstream account are wrongly counted as zero weight. Also walk a permission's parent (e.g. `owner` for `active`) on the same account, since the chain accepts a parent-permission key wherever the child would suffice. Re-verify the no-recursion behavior on any library upgrade.
36
36
37
37
## show_payer rows are unwrapped into ram_payers
38
38
39
-
With `show_payer: true`, the raw `/v1/chain/get_table_rows` endpoint wraps each row as `{ data: <row>, payer: <account> }`. The typed `@wharfkit/antelope` client (`client.v1.chain.get_table_rows`, verified on 1.1.1) unwraps that envelope: it returns the rows flat and moves the payers into a separate `ram_payers` array on the response, index-aligned with `rows`. Code ported from eosjs that expects `row.data` / `row.payer` on each element therefore gets `undefined` on every row (a failure mode that unit tests can miss entirely if they mock the raw nodeos shape the typed client never returns). Either read the payer from `response.ram_payers[i]`, or call `/v1/chain/get_table_rows` directly with `json: true, show_payer: true` to keep the `{data, payer}` row shape; in both cases, stub the actual transport in tests rather than mocking an assumed row shape.
39
+
With `show_payer: true`, the raw `/v1/chain/get_table_rows` endpoint wraps each row as `{ data: <row>, payer: <account> }`. The typed `@wharfkit/antelope` client (`client.v1.chain.get_table_rows`, verified on 1.2.0) unwraps that envelope: it returns the rows flat and moves the payers into a separate `ram_payers` array on the response, index-aligned with `rows`. Code ported from eosjs that expects `row.data` / `row.payer` on each element therefore gets `undefined` on every row (a failure mode that unit tests can miss entirely if they mock the raw nodeos shape the typed client never returns). Either read the payer from `response.ram_payers[i]`, or call `/v1/chain/get_table_rows` directly with `json: true, show_payer: true` to keep the `{data, payer}` row shape; in both cases, stub the actual transport in tests rather than mocking an assumed row shape.
0 commit comments