From 3b9e5fb2fecb9bfbe2d90003659cab6a5d32cd17 Mon Sep 17 00:00:00 2001 From: Rob Konsdorf Date: Tue, 18 Aug 2026 17:08:17 -0400 Subject: [PATCH] docs: re-verify the client-library page at wharfkit antelope 1.2.0 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. --- AGENTS.md | 2 +- CHANGELOG.md | 6 ++++++ reference/validation.md | 4 ++-- reference/wharfkit.md | 8 ++++---- 4 files changed, 13 insertions(+), 7 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index 3527955..825cf36 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -64,6 +64,6 @@ Read the routed file in full rather than searching it. The facts there encode be 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. -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. +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. 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. diff --git a/CHANGELOG.md b/CHANGELOG.md index fe1f6e2..193f6da 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -2,6 +2,12 @@ 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. +## 2026.08.2 + +### Revalidated + +- `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. + ## 2026.08.1 ### Corrected diff --git a/reference/validation.md b/reference/validation.md index b39189a..b04e7a2 100644 --- a/reference/validation.md +++ b/reference/validation.md @@ -16,7 +16,7 @@ This log traces how every fact in `reference/` and `guides/` was checked before - `atomictools-contract` at commit `d89ce79e4` (the upstream repository has no release tag; the deployed `atomictoolsx` ABI on WAX matches this commit exactly) - `atomicassets-sdk` at tag `v2.1.1`, commit `5c70c62` (published as `@atomichub/atomicassets` 2.1.1) - `atomicmarket-sdk` at tag `v2.4.1`, commit `437300b` (published as `@atomichub/atomicmarket` 2.4.1) -- `@wharfkit/antelope` at `1.1.1` +- `@wharfkit/antelope` at `1.2.0` - `@wharfkit/session` at `1.6.1`, with `@wharfkit/common` at `1.5.0` and `@wharfkit/wallet-plugin-privatekey` at `1.1.0` - `@atomichub/vert` at `2.2.0`, commit `a8a4160` - `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 | `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`. | | `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. | | `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. | -| `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. | +| `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. | | `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. | | `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. | | `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. | diff --git a/reference/wharfkit.md b/reference/wharfkit.md index 897e7a3..54f9caa 100644 --- a/reference/wharfkit.md +++ b/reference/wharfkit.md @@ -1,5 +1,5 @@ --- -scope: "@wharfkit/antelope client library behavior for table reads, authority checks, and payer unwrapping, each verified against version 1.1.1 of the package" +scope: "@wharfkit/antelope client library behavior for table reads, authority checks, and payer unwrapping, each verified against version 1.2.0 of the package" depends-on: [] key-modules: - "@wharfkit/antelope" @@ -7,7 +7,7 @@ key-modules: # @wharfkit/antelope client behavior -Version-pinned facts below were verified against 1.1.1; re-check them on upgrade. +Version-pinned facts below were verified against 1.2.0; re-check them on upgrade. ## Typed get_table_rows is not a drop-in for dynamic reads @@ -32,8 +32,8 @@ Typed endpoints such as `get_account` also strict-decode responses into structs, ## hasPermission does not recurse into account weights -`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. +`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. ## show_payer rows are unwrapped into ram_payers -With `show_payer: true`, the raw `/v1/chain/get_table_rows` endpoint wraps each row as `{ data: , payer: }`. 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. +With `show_payer: true`, the raw `/v1/chain/get_table_rows` endpoint wraps each row as `{ data: , payer: }`. 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.