Skip to content

Commit 10bcf09

Browse files
authored
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.
1 parent bc47b5f commit 10bcf09

4 files changed

Lines changed: 13 additions & 7 deletions

File tree

‎AGENTS.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -64,6 +64,6 @@ Read the routed file in full rather than searching it. The facts there encode be
6464

6565
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.
6666

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.
6868

6969
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.

‎CHANGELOG.md‎

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2,6 +2,12 @@
22

33
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.
44

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.
10+
511
## 2026.08.1
612

713
### Corrected

‎reference/validation.md‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -16,7 +16,7 @@ This log traces how every fact in `reference/` and `guides/` was checked before
1616
- `atomictools-contract` at commit `d89ce79e4` (the upstream repository has no release tag; the deployed `atomictoolsx` ABI on WAX matches this commit exactly)
1717
- `atomicassets-sdk` at tag `v2.1.1`, commit `5c70c62` (published as `@atomichub/atomicassets` 2.1.1)
1818
- `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`
2020
- `@wharfkit/session` at `1.6.1`, with `@wharfkit/common` at `1.5.0` and `@wharfkit/wallet-plugin-privatekey` at `1.1.0`
2121
- `@atomichub/vert` at `2.2.0`, commit `a8a4160`
2222
- `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
5656
| `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`. |
5757
| `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. |
5858
| `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. |
6060
| `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. |
6161
| `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. |
6262
| `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. |

‎reference/wharfkit.md‎

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,13 @@
11
---
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"
33
depends-on: []
44
key-modules:
55
- "@wharfkit/antelope"
66
---
77

88
# @wharfkit/antelope client behavior
99

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.
1111

1212
## Typed get_table_rows is not a drop-in for dynamic reads
1313

@@ -32,8 +32,8 @@ Typed endpoints such as `get_account` also strict-decode responses into structs,
3232

3333
## hasPermission does not recurse into account weights
3434

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.
3636

3737
## show_payer rows are unwrapped into ram_payers
3838

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

Comments
 (0)