@onrail-xyz/evm 1.0.0

package/LICENSE

@@ -0,0 +1,201 @@
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

package/README.md

@@ -0,0 +1,301 @@
+# @onrail-xyz/evm
+
+[![npm version](https://img.shields.io/npm/v/@onrail-xyz/evm.svg)](https://www.npmjs.com/package/@onrail-xyz/evm)
+
+Ethereum/EVM utilities built on [viem](https://www.npmjs.com/package/viem). Provides type-safe ERC20, EIP-2612 permit and EIP-3009 authorization interactions, batched on-chain queries via Multicall3, and low-level EVM binary layout primitives.
+
+- [Contract Specs](#contract-specs) – declarative contract interface definitions
+- [ERC20](#erc20) – read/write ERC20 methods via spec
+- [EIP-2612 Permit](#eip-2612-permit) – on-chain permit calls and off-chain message composition
+- [EIP-3009 Authorizations](#eip-3009-authorizations) – transfers by signed authorization, on-chain calls and message composition
+- [Batched Queries](#batched-queries) – Multicall3-based read batching with block-consistent results
+- [EVM Layout Primitives](#evm-layout-primitives) – word-aligned binary layouts, function selectors, storage slot computation
+- [Hashing](#hashing) – keccak256, sha3_256
+
+## Install
+
+```bash
+npm install @onrail-xyz/evm \
+  @onrail-xyz/utils @onrail-xyz/binary-layout @onrail-xyz/common @onrail-xyz/amount \
+  @noble/hashes viem
+```
+
+The `@onrail-xyz/*` packages, `viem`, and `@noble/hashes`, which backs the hash re-exports, are peer dependencies — install them alongside `evm` (recent pnpm/npm auto-install peers; Yarn does not). Peering keeps a single shared `utils` (which anchors the SDK's branded types) and a single `viem` across the consuming app. `@noble/hashes` is accepted at `^1.8 || ^2`: the functions used are the same in both majors, so the copy viem pins serves. Node and TypeScript floors are [SDK-wide](https://github.com/Onrail/ts-sdk#requirements).
+
+## Contract Specs
+
+`contractFromSpec` generates a typed contract interface from a declarative spec: a tuple of `abiFunction(name, params, composer, outputLayout?)` rows.
+
+- **Params** are `abiParam(name, solidityType, item)` triples: the type is the string the ABI uses, the item says how its slot reads. A parameter spanning several words that is not a tuple — a signature's `(v, r, s)` — spells its types comma-joined, `"uint8,bytes32,bytes32"`, so the signature string reads as if they were separate parameters. The surfaced value type is the item's; where `DeriveType` cannot reduce it — an amount at an open kind — `abiParam<V>()(name, type, item)` states it, the zero-argument overload taking `V` alone so the rest stays inferred; `paramOf<V>()(type, item)` is the same door for a factory. Two more exist beside it: `amountParam(name, type, kind?, size?)`, which states `AmountOr<K, NumSizeToPrimitive<S>>` — an `Amount<K>` given a kind, otherwise the primitive the item's width derives — and `trailingBytesParam(name, layout?)`, which carries the dynamic marker `abiParam` cannot express. Note the ABI type and the item's width are independent: the type is what the slot is spelled as, the width is the domain's range, so a `uint64` amount the contract holds is `amountParam(name, "uint256", kind, 8)` — an 8-byte item on a `uint256` word, which rejects a value the contract could not hold where a word-wide item would pass it. What recurs across a domain's tables is the type-and-item pair, not the name, so `paramOf(type, item)` fixes the pair and returns a factory taking the name — `addressParam` is `paramOf("address", addressItem)`, and a domain spells its own the same way (`const usdcParam = paramOf("uint256", usdcItem)`). Beyond that there is no shared parameter vocabulary — names are cheap to spell and each table defines the handful it reuses.
+- **Read calls** (output layout given) return a layout triple `[layout, params, outputLayout]` for use with the query function from `createQuery`.
+- **Write calls** (no output layout) return pre-serialized call data; the sender is the transaction's business, so none is taken. `toViemTx` bridges the result to viem's transaction parameters.
+- The **composer** maps positional arguments to the params object, giving every method both a positional and an object overload. It is typed from the params, so it is written with names only. The two forms are told apart by arity, except for a single object argument to a single-parameter method, which is read as the object form iff its one key is the parameter's name — so a positional record whose sole key happens to be the parameter's name, or an object-form value carrying extra keys, is read the other way. Name such a parameter after something other than its record's only key, or pass the object form with exactly the one key.
+- **Solidity overloads** share an ABI name, so a row whose method key must differ names both, key first: `abiFunction(["safeTransferFromWithData", "safeTransferFrom"], [from, to, tokenId, data], ...)`. The key names the method on the generated interface; the ABI name goes into the selector.
+- **Events and errors** are `[signature, struct]` pairs, listed as the variants of `buildParseEvent` / `buildParseError` (`erc20Events`, say); `sigVariant(name, ...params)` spells one from the same params. The struct is in *wire* order. For an error that is the parameter order. For an event it is the indexed parameters first, then the rest, each group in declaration order — which is `sigVariant`'s param order exactly when the indexed parameters lead the declaration, as they conventionally do. An event whose declaration interleaves them is spelled as a pair directly: the signature in declaration order, the struct in wire order. An indexed `bytes`, `string`, array or struct parameter is its keccak on the wire, so its item is `hashItem`. Since topics and data are read as one sequence, events that share a signature but not its indexing decode alike (ERC-721's `Transfer` indexes the token id that ERC-20's carries as data): parse the logs of known contracts, filtered by address.
+
+The pieces are typed too. A row is a `FuncSpec`, named by a `FuncName` — a string, or a `[key, abiName]` pair whose `FuncKey` names the method. Params are `AbiParam`s (`DynamicAbiParam` for the trailing one), each surfacing its `AbiParamValue`; for a param list, `ParamsStruct` is its items, `ParamsLayout` the call layout they form, and `ParamsRecord` the record the composer builds. `ContractMethods<S>` is the interface `contractFromSpec` generates. A variant is a `SigVariant` (a non-empty tuple of them, `SigVariants`), and `SigVariantOf<N, P>` is the one `sigVariant` spells; `signatureOf(name, params)` is the signature string a spec derives, `sigNameOf`/`SigNameOf` read the name back. `buildParseError` reads revert data and `buildParseEvent` a `ViemLog`, yielding `ParsedError<V>`/`ParsedEvent<V>`; both run on `sigSwitchItem(idSize, tag)`, a *switch* keyed by a signature hash's leading bytes (4 for errors, the whole 32-byte topic for events), whose returned factory is a `SigSwitcher`.
+
+### What specs cover, and what they do not
+
+**This is not a full ABI codec.** A spec lays each parameter out on its ABI slots with `binary-layout`, which buys the typed, branded values this SDK is built on — an `Amount`, a `Deadline`, a domain type — at a fraction of an encoder's cost. The price is that the argument shapes it can express are a subset of the ABI's, and the boundary is *static versus dynamic*, not "primitives versus structs".
+
+Covered:
+
+- Any statically sized parameter — `address`, `bool`, `uintN`, `intN`, `bytesN`. A signed parameter narrower than a word takes the word's own width on the wire, since the ABI sign-extends it, and a value its declared width cannot hold is rejected. A `bytesN` is `bytesNItem(N)`: the one static type the ABI pads on the *right*, so it is spelled at word width, whereas a bare `{ binary: "bytes", size }` on a slot is left-padded like every other value — which is how `addressItem`, a bare 20-byte item, lands on its `uint160` slot.
+- **Static tuples**, which the ABI encodes inline, as one multi-word parameter whose type is paren-spelled: `abiParam("order", "(uint256,address)", { binary: "bytes", layout: { amount: uint256Item, taker: abiAddressItem } })`. A tuple's members each occupy a whole slot, so each is padded individually (`paddedFields` does that for a struct of sub-word items). Nesting is fine as long as every member is static.
+- **Fixed-size arrays of static types** (`uint256[2]`), likewise inline.
+- **One trailing dynamic argument**, via `trailingBytesParam(name, layout?)` — the common `f(..., bytes data)` shape (CCTP's `messageBody` and `hookData`, Uniswap v4's `hookData`). Given a `layout` it carries that structure's serialization rather than raw bytes.
+- **A single dynamic return value.** An output layout is handed straight to `deserialize` rather than laid out on slots, so `abiEncodedBytesItem` spells one — which is what `erc20`'s `name` and `symbol` do. It is an `AbiEncodedBytesItem<L>`, deriving `AbiEncoded<L>`: the content layout's type, or raw bytes without one. Several of them hit the same offset problem as several dynamic arguments.
+
+Not covered:
+
+- **Dynamic arrays** — `address[]`, `uint256[]`, `bytes[]`.
+- **More than one dynamic parameter**, or one that is not last. With two, each offset depends on the lengths of the tails ahead of it; nothing constant remains to bake into a layout, which is where clever layouts end and an encoder begins. A spec that asks for this through `trailingBytesParam` anywhere but last throws when it is built. A plain `abiParam` is not parsed for its type string: the item is the author's statement of how the slots read, and the type string is only what goes into the selector, so a dynamic type over a static item is the author's error and encodes inline, wrongly.
+- **Dynamic tuples** — a tuple with any dynamic member is itself dynamic, offset pointer and all.
+
+These exclusions are somewhat common: ERC-1155's `safeBatchTransferFrom(address,address,uint256[],uint256[],bytes)` and any router taking a multi-hop path or a batch of calls fall within that limitation and require a complete encoder like viem's `encodeFunctionData`.
+
+
+```ts
+import { contractFromSpec, abiFunction, addressParam, amountParam, evmAmountItem } from "@onrail-xyz/evm";
+
+//a spec's parameter vocabulary is its own
+const owner = addressParam("owner");
+const to    = addressParam("to");
+const value = amountParam("value", "uint256");
+
+const spec = [
+  abiFunction("balanceOf", [owner],     owner => ({ owner }),           evmAmountItem()),
+  abiFunction("transfer",  [to, value], (to, value) => ({ to, value })),
+] as const;
+
+const contract = contractFromSpec("0xA0b8...eB48", spec);
+
+// Read call — returns { to, data: [layout, params, outputLayout] }
+const call = contract.balanceOf({ owner: "0xd8dA...6045" });
+
+// Write call — returns { to, data: Uint8Array }
+const tx = contract.transfer({ to: "0xd8dA...6045", value: 500n });
+```
+
+`toViemTx` converts a `ContractTx` — a write call's result, optionally carrying a `from`, a `value` and an access list — into viem's transaction parameters (a `ViemTx`): call data as hex, the value as an atomic `bigint`, and the sender under viem's name for it, `account`.
+
+```ts
+import { toViemTx } from "@onrail-xyz/evm";
+
+await walletClient.sendTransaction(toViemTx(tx));
+```
+
+`addressItem` surfaces the EIP-55 checksummed spelling, matching what viem's decoders return — a lowercase one would make the same word decode to two strings that compare unequal. Either spelling is accepted on the way in.
+
+## ERC20
+
+Built on `contractFromSpec`. Provides `name`, `symbol`, `decimals`, `totalSupply`, `balanceOf`, `allowance`, `approve`, `transfer`, and `transferFrom`. The optional `kind` parameter enables typed `Amount` values via `@onrail-xyz/amount`.
+
+`erc20Events` lists `Transfer` and `Approval` as variants for `buildParseEvent`. `allowanceAdjusters` provides `increaseAllowance` and `decreaseAllowance` the same way as `erc20`. They are OpenZeppelin's extension rather than ERC-20, dropped from OpenZeppelin 5.0 but implemented by USDC and most tokens built on earlier releases, hence a spec of their own.
+
+```ts
+import { createPublicClient, http } from "viem";
+import { mainnet } from "viem/chains";
+import { erc20, createQuery } from "@onrail-xyz/evm";
+
+const client = createPublicClient({ chain: mainnet, transport: http() });
+const query = createQuery(client);
+const usdc = erc20("0xA0b8...eB48");
+
+// Read calls — use with the query function from createQuery
+const [[name, decimals, balance]] = await query([
+  usdc.name(),
+  usdc.decimals(),
+  usdc.balanceOf({ owner: "0xd8dA...6045" }),
+]);
+
+// Write calls
+const approveTx = usdc.approve({ spender: spenderAddr, value: 1000n });
+const transferTx = usdc.transfer({ to: toAddr, value: 500n });
+```
+
+## EIP-2612 Permit
+
+### On-chain calls
+
+The `permit` function provides `DOMAIN_SEPARATOR`, `nonces`, and `permit` methods via `contractFromSpec`:
+
+```ts
+import { permit } from "@onrail-xyz/evm";
+
+const p = permit("0xA0b8...eB48");
+
+// Read the domain separator and nonce
+const [[domainSep, nonce]] = await query([
+  p.DOMAIN_SEPARATOR(),
+  p.nonces({ owner: ownerAddr }),
+]);
+
+// Submit a permit
+const tx = p.permit({
+  owner: ownerAddr, spender: spenderAddr, value: 1000n,
+  deadline: new Date("2030-01-01"), signature,
+});
+```
+
+`deadline` is a `Date` or `"infinity"`, the latter encoding the maxed out uint256 that means "never expires". `signature` is the 65 packed bytes a signer returns (`hex.decode(await walletClient.signTypedData(...))`); the spec spreads them over the `v`, `r`, `s` words the Solidity signature takes (`abiSignatureItem`), so nothing is split by hand. `signatureItem` carries the packed bytes as is and `compactSignatureItem` EIP-2098's 64-byte form; all three type the signature as the packed bytes. `signatureSize` is those 65 bytes, and `signatureLayout`/`abiSignatureLayout` are the structs behind the items — `r`, `s`, `v` packed, and `v`, `r`, `s` on words. The deadline is `deadlineItem`, a word-wide timestamp saturating at `"infinity"` (a `Deadline`); `evmTimestampItem` is the same word without the sentinel.
+
+### Off-chain message composition
+
+`guessEip712Domain` reconstructs the EIP-712 domain from on-chain data by brute-forcing the version field against the domain separator hash. It covers the `{ name, chainId, verifyingContract }` domain with an optional version, i.e. tokens following EIP-2612's reference implementation. `composePermitMsg` builds an EIP-2612 permit, and `toViemTypedData` hands it to viem: a composed message keeps its `bytes32` values (the domain's `salt`, an EIP-3009 `nonce`) as byte arrays and an all-optional domain, whereas viem wants hex and derives the domain's required fields from `types.EIP712Domain`. A message is an `Eip712Message<F>`, the object its `Eip712Field` list describes, and a composed one an `Eip712Data` (`Eip2612Message`/`Eip2612Data` for a permit) with an `Eip712Domain`; `toViemTypedData` returns a `ViemTypedData<T>`, and `eip712DomainType(domain)` is the domain's field list as viem derives it.
+
+Only EIP-2612 is covered — DAI-style permits (`nonce`/`expiry`/`allowed` instead of `value`/`deadline`, and hence a different struct and selector) need their own spec.
+
+```ts
+import { composePermitMsg, guessEip712Domain, toViemTypedData } from "@onrail-xyz/evm";
+
+const domain = guessEip712Domain(
+  tokenName, contractAddress, chainId, domainSeparator,
+);
+
+const permitData = composePermitMsg(
+  owner, spender, amount, domain, nonce,
+  deadline, // optional — defaults to max uint256
+);
+
+const signature = await walletClient.signTypedData(toViemTypedData(permitData));
+```
+
+`eip712EncodeDataLayout(fields)` spells a struct's `encodeData` as a layout, an `Eip712EncodeDataLayout<F>`: each atomic field (`bool`, `address`, `uintN`, `intN`, `bytesN`) on a word, in field order. Serializing a message through it yields the bytes `hashStruct` hashes after the type hash, and deserializing derives a message from any data that already has a word-per-field layout — a command a contract also accepts through its ABI, say — so the message need not be composed by hand. It is atomic-only: a dynamic, array or struct-typed field takes a word holding a hash rather than the value, which the layout does not compute, so a field list with one is rejected.
+
+## EIP-3009 Authorizations
+
+[EIP-3009](https://eips.ethereum.org/EIPS/eip-3009) moves tokens on the holder's signature alone: whoever submits the authorization pays the gas, and the receiving variant additionally requires the submitter to be the recipient. `erc3009` provides `authorizationState`, `transferWithAuthorization`, `receiveWithAuthorization` and `cancelAuthorization` via `contractFromSpec`; USDC implements the standard.
+
+```ts
+import { erc3009, composeTransferWithAuthorizationMsg, randomAuthorizationNonce, toViemTypedData } from "@onrail-xyz/evm";
+
+const nonce = randomAuthorizationNonce();
+const authorization = composeTransferWithAuthorizationMsg(
+  holder, recipient, amount, domain, nonce,
+  validBefore, // optional — defaults to max uint256
+  validAfter,  // optional — defaults to the epoch, i.e. valid immediately
+);
+const signature = await walletClient.signTypedData(toViemTypedData(authorization));
+
+const a = erc3009("0xA0b8...eB48");
+const tx = a.transferWithAuthorization({
+  from: holder, to: recipient, value: amount, validAfter, validBefore, nonce,
+  signature: hex.decode(signature),
+});
+
+// A pending authorization is revoked by its holder through a second signature
+const cancellation = composeCancelAuthorizationMsg(holder, domain, nonce);
+```
+
+`composeReceiveWithAuthorizationMsg` is the receiving variant's twin, taking the same arguments; the messages are `Eip3009AuthorizationMessage` and `Eip3009CancelMessage`.
+
+Nonces are 32 random bytes rather than a counter, so several authorizations can stand at once and composing one needs no chain state; `authorizationState(authorizer, nonce)` reads whether a nonce has been used or canceled, and `erc3009Events` lists the standard's `AuthorizationUsed` / `AuthorizationCanceled` for `buildParseEvent`. The standard leaves revert reasons to implementations, so none are listed.
+
+## Batched Queries
+
+`createQuery(client)` returns a `query` function that batches arbitrary read calls into a single [Multicall3](https://www.multicall3.com/) request and returns the results together with the block they were read from — so all reads come from the same point in time.
+
+Consistency is not merely a matter of batching: the block tag is first resolved to a block hash, and the batch is then executed against that hash with `requireCanonical`, so a reorg fails the query (and is retried) instead of silently mixing states. This requires an RPC that supports [EIP-1898](https://eips.ethereum.org/EIPS/eip-1898) block hash parameters, plus archive state for blocks beyond the pruning window.
+
+```ts
+import { createPublicClient, http } from "viem";
+import { mainnet } from "viem/chains";
+import { createQuery, erc20 } from "@onrail-xyz/evm";
+
+const client = createPublicClient({ chain: mainnet, transport: http() });
+const query = createQuery(client);
+
+const token = erc20("0xA0b8...eB48");
+
+const [[balance, allowance], blockNumber, blockHash, blockTime] = await query(
+  [
+    token.balanceOf({ owner: "0xd8dA...6045" }),
+    token.allowance({ owner: "0xd8dA...6045", spender: "0xBEEF...0000" }),
+  ],
+  "latest",
+);
+```
+
+The block can also be given as a number, as `"finalized"`, or as a block hash — the latter pins the query directly and hence yields the results only, without the block meta tuple. The types follow: the block is a `BlockSpec`, the results a `QueryResult` or `QueryResultWithMeta`, and `Query` is the function `createQuery` returns.
+
+A call is a `QueryCall`, and its data a `QueryCallData` in one of three formats — raw bytes, a `QueryLayoutTriple`, or a `QueryAbiPair` whose result is its `QueryAbiReturn` — which mix freely, even within the same batch:
+
+```ts
+const [[rawBytes, amount, viemDecoded]] = await query(
+  [
+    // 1. Raw bytes — pre-serialized in, raw bytes out
+    { to: tokenAddr, data: serialize(balanceOfLayout, { owner }) },
+    // 2. Layout triple — deserialized via the output layout
+    { to: tokenAddr, data: [balanceOfLayout, { owner }, evmAmountItem(ethKind)] },
+    // 3. Function signature — viem ABI-encodes the call and decodes the return
+    { to: tokenAddr, data: ["balanceOf(address) view returns (uint256)", [owner]] },
+  ],
+  "latest",
+);
+```
+
+A reverting call fails the whole query unless it opts into `allowFailure`, which turns its result into a `{ success, data }` pair — with the raw revert data on failure — while the rest of the batch is unaffected:
+
+```ts
+const [[maybeAllowance]] = await query([
+  { to: tokenAddr, data: [allowanceLayout, { owner, spender }, uint256Item], allowFailure: true },
+]);
+if (maybeAllowance.success)
+  console.log(maybeAllowance.data);
+```
+
+## EVM Layout Primitives
+
+The plumbing that the rest of the package is built on. Layout items for EVM's 32-byte word-aligned world, function selector helpers, and storage slot computation — all plugging into `@onrail-xyz/binary-layout`.
+
+```ts
+import {
+  uint256Item,
+  addressItem,
+  bytesNItem,
+  signatureItem,
+  selectorOf,
+  selectorLayout,
+  evmAmountItem,
+  mappingSlot,
+  paddedSlotLayout,
+  paddedFields,
+} from "@onrail-xyz/evm";
+
+// Compute a 4-byte function selector — the signature must be canonical, i.e. no parameter
+//   names, no whitespace, and no type aliases (`uint256`, not `uint`)
+const sel = selectorOf("transfer(address,uint256)");
+
+// Wrap a struct with a function selector prefix
+const transferLayout = selectorLayout("transfer(address,uint256)")({
+  to:    paddedSlotLayout(addressItem),
+  value: uint256Item,
+});
+
+// The ABI's bytes4 on its word: right-padded, unlike everything else on a slot
+const tag = bytesNItem(4);
+
+// Compute a Solidity mapping storage slot
+const slot = mappingSlot(key, declarationSlot);
+
+// Put every field of a struct on a slot of its own - the ABI's static parameter list
+const paramsLayout = paddedFields({ to: addressItem, value: uint256Item, flag: boolItem() });
+```
+
+**Storage slots:** `mappingSlot(key, slot)` hashes `key . slot` for a value-type key, padded to the word the way Solidity pads its type, which the key's JS type names: a `bigint`/`number` is an integer (a negative one sign-extended), a `boolean` a bool, an `Address` an address — all right-aligned — and a `Uint8Array` a `bytesN`, left-aligned, so a full word is itself (chain the calls for nested mappings; `string`/`bytes` keys are hashed unpadded and are not covered). `keccakSlot(slot)` yields the first element's slot of a dynamic array.
+
+**More items:** `abiBoolItem` is a bool on its word, `selectorItem(sig)` a selector as a fixed constant, and `addressConversion` the EIP-55 conversion `addressItem` (an `AddressItem`) carries. `paddedSlotLayout` makes a `PaddedSlotLayout<T>` of an item — for a signed one a `SignedSlotItem`, sign-extended onto the word — and `paddedFields` a `PaddedFields<S>`; `bytesNItem(N)` is a `BytesNItem<N>`, and a mapping key a `MappingKey`.
+
+**Constants:** `wordSize` (32), `addressSize` (20), `selectorLength` (4).
+
+## Hashing
+
+Re-exports of the hashes the EVM runs on, from [@noble/hashes](https://github.com/paulmillr/noble-hashes):
+
+```typescript
+import { keccak256, sha3_256 } from "@onrail-xyz/evm";
+```
+
+`keccak256` is the pre-standardization padding Ethereum uses, not `sha3_256` — the two disagree on every input.

package/dist/client.d.ts

@@ -0,0 +1,56 @@
+import type { Address, AccessList, Hex } from "viem";
+import type { RoUint8Array, RoTuple, Function, OptionalArg } from "@onrail-xyz/utils";
+import type { Layout } from "@onrail-xyz/binary-layout";
+import type { KindWithAtomic } from "@onrail-xyz/amount";
+import { type AmountOrAtomic } from "@onrail-xyz/common";
+import type { AbiParam, AbiParamValue, PaddedSlotLayout } from "./layouting.js";
+import type { QueryLayoutTriple } from "./query.js";
+export type ContractTx<K extends KindWithAtomic | undefined = KindWithAtomic | undefined> = {
+    to: Address;
+    from?: Address;
+    value?: AmountOrAtomic<K>;
+    data: RoUint8Array;
+    accessList?: AccessList;
+};
+export type ViemTx = {
+    readonly to: Address;
+    readonly data: Hex;
+    readonly account?: Address;
+    readonly value?: bigint;
+    readonly accessList?: AccessList;
+};
+export declare const toViemTx: (tx: ContractTx) => ViemTx;
+export type ParamsStruct<P extends RoTuple<AbiParam>> = {
+    readonly [E in P[number] as E["name"]]: E["item"];
+};
+export type ParamsLayout<P extends RoTuple<AbiParam>> = {
+    readonly [E in P[number] as E["name"]]: E extends {
+        readonly dynamic: object;
+    } ? E["item"] : PaddedSlotLayout<E["item"]>;
+};
+type ParamValues<P extends RoTuple<AbiParam>> = {
+    [K in keyof P]: P[K] extends AbiParam ? AbiParamValue<P[K]> : never;
+};
+export type ParamsRecord<P extends RoTuple<AbiParam>> = {
+    readonly [E in P[number] as E["name"]]: AbiParamValue<E>;
+};
+export type FuncName = string | readonly [key: string, abiName: string];
+export type FuncKey<N extends FuncName> = N extends readonly [infer K extends string, string] ? K : N;
+export type FuncSpec<N extends FuncName = FuncName, P extends RoTuple<AbiParam> = RoTuple<AbiParam>, C extends Function<any> = Function<any>, R extends Layout | undefined = Layout | undefined> = readonly [N, P, C, R];
+type ContractSpec = RoTuple<FuncSpec>;
+export declare const abiFunction: <const N extends FuncName, const P extends RoTuple<AbiParam>, C extends (...args: ParamValues<P>) => ParamsRecord<P>, const R extends Layout | undefined = undefined>(name: N, params: P, composer: C, ...output: OptionalArg<R>) => FuncSpec<N, P, C, R>;
+type ReadResult<P extends RoTuple<AbiParam>, OL extends Layout> = {
+    readonly to: Address;
+    readonly data: QueryLayoutTriple<ParamsLayout<P>, OL>;
+};
+type WriteResult = Readonly<{
+    to: Address;
+    data: Uint8Array;
+}>;
+type ContractMethodOf<P extends RoTuple<AbiParam>, OL, C extends Function<any>> = OL extends Layout ? ((params: ParamsRecord<P>) => ReadResult<P, OL>) & ((...args: Parameters<C>) => ReadResult<P, OL>) : ((params: ParamsRecord<P>) => WriteResult) & ((...args: Parameters<C>) => WriteResult);
+export type ContractMethods<S extends RoTuple<any>> = {
+    readonly [E in S[number] as E extends FuncSpec<infer N> ? FuncKey<N> : never]: E extends FuncSpec<FuncName, infer P, infer C, infer OL> ? ContractMethodOf<P, OL, C> : never;
+};
+export declare const contractFromSpec: <const S extends ContractSpec>(contract: Address, spec: S) => ContractMethods<S>;
+export {};
+//# sourceMappingURL=client.d.ts.map

package/dist/client.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"client.d.ts","sourceRoot":"","sources":["../src/client.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,OAAO,EAAE,UAAU,EAAE,GAAG,EAAE,MAAM,MAAM,CAAC;AACrD,OAAO,KAAK,EAAE,YAAY,EAAW,OAAO,EAAE,QAAQ,EAAE,WAAW,EAAE,MAAM,mBAAmB,CAAC;AAE/F,OAAO,KAAK,EAAE,MAAM,EAAU,MAAM,2BAA2B,CAAC;AAEhE,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,oBAAoB,CAAC;AACzD,OAAO,EAAE,KAAK,cAAc,EAAoB,MAAM,oBAAoB,CAAC;AAC3E,OAAO,KAAK,EAAE,QAAQ,EAAE,aAAa,EAAmB,gBAAgB,EAAE,MAAM,gBAAgB,CAAC;AAGjG,OAAO,KAAK,EAAE,iBAAiB,EAAE,MAAM,YAAY,CAAC;AAQpD,MAAM,MAAM,UAAU,CAAC,CAAC,SAAS,cAAc,GAAG,SAAS,GAAG,cAAc,GAAG,SAAS,IAAI;IAC1F,EAAE,EAAW,OAAO,CAAC;IACrB,IAAI,CAAC,EAAQ,OAAO,CAAC;IACrB,KAAK,CAAC,EAAO,cAAc,CAAC,CAAC,CAAC,CAAC;IAC/B,IAAI,EAAS,YAAY,CAAC;IAC1B,UAAU,CAAC,EAAE,UAAU,CAAC;CACzB,CAAC;AAEF,MAAM,MAAM,MAAM,GAAG;IACnB,QAAQ,CAAC,EAAE,EAAW,OAAO,CAAC;IAC9B,QAAQ,CAAC,IAAI,EAAS,GAAG,CAAC;IAC1B,QAAQ,CAAC,OAAO,CAAC,EAAK,OAAO,CAAC;IAC9B,QAAQ,CAAC,KAAK,CAAC,EAAO,MAAM,CAAC;IAC7B,QAAQ,CAAC,UAAU,CAAC,EAAE,UAAU,CAAC;CAClC,CAAC;AAKF,eAAO,MAAM,QAAQ,OAAQ,UAAU,KAAG,MAMxC,CAAC;AAgBH,MAAM,MAAM,YAAY,CAAC,CAAC,SAAS,OAAO,CAAC,QAAQ,CAAC,IAClD;IAAE,QAAQ,EAAE,CAAC,IAAI,CAAC,CAAC,MAAM,CAAC,IAAI,CAAC,CAAC,MAAM,CAAC,GAAG,CAAC,CAAC,MAAM,CAAC;CAAE,CAAC;AAIxD,MAAM,MAAM,YAAY,CAAC,CAAC,SAAS,OAAO,CAAC,QAAQ,CAAC,IAAI;IACtD,QAAQ,EAAE,CAAC,IAAI,CAAC,CAAC,MAAM,CAAC,IAAI,CAAC,CAAC,MAAM,CAAC,GACnC,CAAC,SAAS;QAAE,QAAQ,CAAC,OAAO,EAAE,MAAM,CAAA;KAAE,GAAG,CAAC,CAAC,MAAM,CAAC,GAAG,gBAAgB,CAAC,CAAC,CAAC,MAAM,CAAC,CAAC;CACnF,CAAC;AAGF,KAAK,WAAW,CAAC,CAAC,SAAS,OAAO,CAAC,QAAQ,CAAC,IAC1C;KAAG,CAAC,IAAI,MAAM,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,SAAS,QAAQ,GAAG,aAAa,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,GAAG,KAAK;CAAE,CAAC;AAC1E,MAAM,MAAM,YAAY,CAAC,CAAC,SAAS,OAAO,CAAC,QAAQ,CAAC,IAClD;IAAE,QAAQ,EAAE,CAAC,IAAI,CAAC,CAAC,MAAM,CAAC,IAAI,CAAC,CAAC,MAAM,CAAC,GAAG,aAAa,CAAC,CAAC,CAAC;CAAE,CAAC;AAE/D,MAAM,MAAM,QAAQ,GAAG,MAAM,GAAG,SAAS,CAAC,GAAG,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,CAAC,CAAC;AACxE,MAAM,MAAM,OAAO,CAAC,CAAC,SAAS,QAAQ,IACpC,CAAC,SAAS,SAAS,CAAC,MAAM,CAAC,SAAS,MAAM,EAAE,MAAM,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC;AAE9D,MAAM,MAAM,QAAQ,CAClB,CAAC,SAAS,QAAQ,GAAc,QAAQ,EACxC,CAAC,SAAS,OAAO,CAAC,QAAQ,CAAC,GAAK,OAAO,CAAC,QAAQ,CAAC,EACjD,CAAC,SAAS,QAAQ,CAAC,GAAG,CAAC,GAAS,QAAQ,CAAC,GAAG,CAAC,EAC7C,CAAC,SAAS,MAAM,GAAG,SAAS,GAAI,MAAM,GAAG,SAAS,IAChD,SAAS,CAAC,CAAC,EAAE,CAAC,EAAE,CAAC,EAAE,CAAC,CAAC,CAAC;AAC1B,KAAK,YAAY,GAAG,OAAO,CAAC,QAAQ,CAAC,CAAC;AAGtC,eAAO,MAAM,WAAW,GACtB,KAAK,CAAC,CAAC,SAAS,QAAQ,EACxB,KAAK,CAAC,CAAC,SAAS,OAAO,CAAC,QAAQ,CAAC,EAC3B,CAAC,SAAS,CAAC,GAAG,IAAI,EAAE,WAAW,CAAC,CAAC,CAAC,KAAK,YAAY,CAAC,CAAC,CAAC,EAC5D,KAAK,CAAC,CAAC,SAAS,MAAM,GAAG,SAAS,GAAG,SAAS,QACxC,CAAC,UAAU,CAAC,YAAY,CAAC,aAAa,WAAW,CAAC,CAAC,CAAC,KAAG,QAAQ,CAAC,CAAC,EAAE,CAAC,EAAE,CAAC,EAAE,CAAC,CACzC,CAAC;AAE1C,KAAK,UAAU,CAAC,CAAC,SAAS,OAAO,CAAC,QAAQ,CAAC,EAAE,EAAE,SAAS,MAAM,IAAI;IAChE,QAAQ,CAAC,EAAE,EAAI,OAAO,CAAC;IACvB,QAAQ,CAAC,IAAI,EAAE,iBAAiB,CAAC,YAAY,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC;CACvD,CAAC;AAEF,KAAK,WAAW,GAAG,QAAQ,CAAC;IAC1B,EAAE,EAAI,OAAO,CAAC;IACd,IAAI,EAAE,UAAU,CAAC;CAClB,CAAC,CAAC;AAMH,KAAK,gBAAgB,CAAC,CAAC,SAAS,OAAO,CAAC,QAAQ,CAAC,EAAE,EAAE,EAAE,CAAC,SAAS,QAAQ,CAAC,GAAG,CAAC,IAC5E,EAAE,SAAS,MAAM,GACf,CAAC,CAAC,MAAM,EAAE,YAAY,CAAC,CAAC,CAAC,KAAK,UAAU,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,GAChD,CAAC,CAAC,GAAG,IAAI,EAAE,UAAU,CAAC,CAAC,CAAC,KAAK,UAAU,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,GAC/C,CAAC,CAAC,MAAM,EAAE,YAAY,CAAC,CAAC,CAAC,KAAK,WAAW,CAAC,GAC1C,CAAC,CAAC,GAAG,IAAI,EAAE,UAAU,CAAC,CAAC,CAAC,KAAK,WAAW,CAAC,CAAC;AAE9C,MAAM,MAAM,eAAe,CAAC,CAAC,SAAS,OAAO,CAAC,GAAG,CAAC,IAAI;IACpD,QAAQ,EAAE,CAAC,IAAI,CAAC,CAAC,MAAM,CAAC,IAAI,CAAC,SAAS,QAAQ,CAAC,MAAM,CAAC,CAAC,GAAG,OAAO,CAAC,CAAC,CAAC,GAAG,KAAK,GAC1E,CAAC,SAAS,QAAQ,CAAC,QAAQ,EAAE,MAAM,CAAC,EAAE,MAAM,CAAC,EAAE,MAAM,EAAE,CAAC,GACtD,gBAAgB,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC,CAAC,GAC1B,KAAK;CACV,CAAC;AA8BF,eAAO,MAAM,gBAAgB,GAAI,KAAK,CAAC,CAAC,SAAS,YAAY,YACjD,OAAO,QACP,CAAC,KACV,eAAe,CAAC,CAAC,CAwCnB,CAAC"}