WindStack SDK 1.0 release hardening

.github/workflows/validate.yml

@@ -5,7 +5,7 @@ on:
   push:
     branches:
       - main
-      - feat/native-antelope-sdk-v1
+      - audit/release-1.0.0-hardening
   pull_request:
 
 permissions:
@@ -25,11 +25,25 @@ jobs:
       - name: Set up Node.js
         uses: actions/setup-node@v6
         with:
-          node-version: "24"
+          node-version-file: ".nvmrc"
           package-manager-cache: false
       - name: Install dependencies
-        run: npm install --no-audit --no-fund
-      - name: Validate native Antelope packages
-        run: npm run validate:native
-      - name: Validate full SDK
-        run: npm run validate
+        run: npm ci
+      - name: Check formatting
+        run: npm run format:check
+      - name: Check release metadata
+        run: npm run check:release
+      - name: Build native Antelope packages
+        run: npm run build:native
+      - name: Test native Antelope packages
+        run: npm run test:native
+      - name: Test Vexanium ABI fixtures
+        run: npm run test:vexanium-abi
+      - name: Build all packages
+        run: npm run build
+      - name: Run regression tests
+        run: npm test
+      - name: Check native package tarballs
+        run: npm run pack:native
+      - name: Audit native production dependencies
+        run: npm run audit:native

README.md

@@ -1,66 +1,83 @@
 # WindStack SDK
 
-Modern TypeScript SDKs for Antelope/Vexanium, Wisp Wallet, EVM, and Solana.
+WindStack provides TypeScript packages for Vexanium and Antelope applications, Wisp Wallet, EVM providers, and Solana providers.
 
-**Created by Gilang Ramadan** · Copyright © 2026 PT WIND KRIPTOGRAFI TEKNOLOGI · MIT.
+Created by **Gilang Ramadan**. Copyright © 2026 PT WIND KRIPTOGRAFI TEKNOLOGI.
 
-## Native Antelope v1
+## Overview
 
-The new Antelope stack is built from protocol specifications and Web-standard APIs; it is **not a WharfKit fork**.
+The Vexanium and Antelope packages are separated by responsibility so applications can install only the capabilities they need.
 
 | Package | Purpose |
 | --- | --- |
-| `@windstack/crypto` | K1/R1 private keys, public keys, recoverable signatures, Antelope encodings |
-| `@windstack/abi` | ABI binary codec, names/assets/symbols, structs, aliases, variants |
-| `@windstack/rpc` | Typed nodeos RPC with timeout/failover/AbortSignal |
-| `@windstack/contract` | ABI-aware actions, tables and ABI cache |
-| `@windstack/account` | Account, token balance and system-action helpers |
-| `@windstack/antelope` | TAPOS, transaction serialization, digest, signing, broadcast, unified client |
-| `@windstack/session` | Native SessionKit-style wallet/session orchestration |
+| `@windstack/crypto` | K1 and R1 keys, signatures, verification, recovery, and Vexanium-compatible key encoding |
+| `@windstack/abi` | ABI serialization and deserialization for actions, tables, structs, variants, and binary extensions |
+| `@windstack/rpc` | Chain RPC with endpoint failover, request timeouts, cancellation, and structured errors |
+| `@windstack/contract` | Contract ABI loading, action serialization, table queries, and shared ABI caching |
+| `@windstack/account` | VEX balances, transfers, staking, RAM, voting, producers, accounts, and permissions |
+| `@windstack/antelope` | TAPOS, transaction serialization, signing digests, required keys, signing, and broadcast |
+| `@windstack/session` | Wallet plugins, sessions, persistence, restore, and transaction orchestration |
 
-The v1 native package graph does not depend on `@wharfkit/*`, `elliptic`, `bn.js`, `crypto-browserify`, or Node Buffer APIs. Crypto primitives use current Noble packages (`@noble/curves` and `@noble/hashes`). Noble v2 is ESM-only, so Node.js **20.19+** is required when running directly on Node.
+Vexanium Mainnet is available as a first-class preset with the canonical chain ID, RPC endpoint, `vexcore` system contract, `vex.token` native token contract, `VEX` symbol, and precision `4`.
+
+Additional packages provide Wisp provider interfaces and chain-specific helpers for VEX Native, VEX EVM, and Solana wallet integrations.
+
+## Installation
+
+Install the high-level transaction client and session package:
 
 ```bash
 npm install @windstack/antelope @windstack/session
 ```
 
-```ts
-import { AntelopeClient } from "@windstack/antelope";
-
-const client = new AntelopeClient({ endpoints: ["https://api.windcrypto.com"] });
-const token = client.contract("vex.token");
-const action = await token.action("transfer", {
-  from: "alice",
-  to: "bob",
-  quantity: "1.0000 VEX",
-  memo: "WindStack",
-}, ["alice@active"]);
-```
-
-## Existing packages
-
-`@windstack/core`, `@windstack/evm`, `@windstack/solana`, `@windstack/vexanium`, and `@windstack/wallet-plugin-wisp` remain in this monorepo for compatibility. The legacy Vexanium/WharfKit integration is not a dependency of the seven native Antelope v1 packages above.
+Individual packages can also be installed independently.
 
-## Development
+## Usage
 
-```bash
-npm install
-npm run validate:native
-npm run validate
+```ts
+import {
+  PrivateKey,
+  PrivateKeySigner,
+} from "@windstack/antelope";
+import {
+  VEXANIUM_MAINNET,
+  createVexaniumClient,
+} from "@windstack/antelope/vexanium";
+
+const client = createVexaniumClient();
+
+console.log(VEXANIUM_MAINNET.contracts.system); // vexcore
+console.log(VEXANIUM_MAINNET.contracts.token); // vex.token
+console.log(VEXANIUM_MAINNET.nativeToken.symbol); // VEX
+
+const signer = new PrivateKeySigner([
+  PrivateKey.fromString("PVT_K1_..."),
+]);
+
+const transfer = await client
+  .account("alice")
+  .transfer("bob", "1.0000 VEX", "WindStack");
+
+const result = await client.transact({
+  actions: [transfer],
+  signer,
+});
+
+console.log(result.response);
 ```
 
-## Publish native packages from VPS
+Applications should keep private keys in an appropriate secure storage or signing service. Wallet integrations can provide their own `Signer` implementation so application code never receives private-key material.
 
-Authenticate to npm first (`npm whoami`). Then:
+## Runtime
 
-```bash
-npm install
-npm run release:dry-run
-npm run release:npm
-```
+The seven release packages are ESM-first and use Web-standard primitives such as `Uint8Array`, `TextEncoder`, `fetch`, `AbortController`, and secure platform randomness. Node.js 20.19 or newer is supported. Browser and React Native environments must provide the Web APIs used by the selected package.
+
+K1 and R1 cryptographic operations are provided by the Noble libraries. The seven-package transaction stack does not depend on `elliptic`, `bn.js`, or Node.js crypto polyfills.
 
-`release:npm` publishes only the seven native packages, in dependency order.
+Release validation checks package metadata, formatting, documentation, dependency boundaries, tests, package contents, and the current production ABIs for `vexcore` and `vex.token`.
 
 ## License
 
-MIT. Created by Gilang Ramadan; copyright PT WIND KRIPTOGRAFI TEKNOLOGI.
+MIT License.
+
+Created by **Gilang Ramadan**. Copyright © 2026 PT WIND KRIPTOGRAFI TEKNOLOGI.

VEXANIUM-PROVIDER-V1.md

@@ -1,16 +1,18 @@
 # VexaniumProvider v1
 
+## Overview
+
+`VexaniumProvider` defines the browser-facing contract between a Vexanium dApp and a compatible wallet provider. It standardizes provider identity, capability negotiation, account access, exact transaction signing, portable signing requests, events, errors, discovery, and the security boundary used for wallet permissions.
+
 Protocol identifier: `VexaniumProvider`
 
 Protocol version: `1.0.0`
 
-SDK release implementing this contract: `0.6.0`
-
-This document defines the wire contract between a dApp and an injected Vexanium wallet. Antelope transaction encoding and signing-request payloads remain defined by WharfKit and the Antelope protocol.
+Created by **Gilang Ramadan**.
 
-## 1. Provider object
+## Provider object
 
-A compatible wallet provider MUST expose:
+A compatible provider exposes the following interface:
 
 ```ts
 interface VexaniumProvider {
@@ -22,10 +24,10 @@ interface VexaniumProvider {
 }
 ```
 
-`providerInfo` is mandatory and MUST include:
+`providerInfo` is required and contains the provider identity and supported Vexanium capabilities:
 
 ```ts
-{
+interface VexaniumProviderInfo {
   uuid: string;
   name: string;
   rdns: string;
@@ -37,19 +39,19 @@ interface VexaniumProvider {
 }
 ```
 
-A dApp MUST NOT invent missing provider identity. Discovery ignores providers that do not satisfy the v1 shape.
+A client must not invent missing provider identity. Providers that do not expose the required v1 shape are ignored during discovery.
 
-## 2. Version compatibility
+## Version compatibility
 
-The SDK and wallet negotiate semantic protocol versions through `vex_getCapabilities`.
+The client and wallet negotiate semantic protocol versions through `vex_getCapabilities`.
 
-For protocol v1, compatible implementations MUST share major version `1`. A `2.x` provider is not implicitly compatible with a `1.x` SDK.
+Implementations of protocol v1 must share major version `1`. A provider using another major version is not considered compatible unless a future specification explicitly defines that compatibility.
 
-## 3. Capabilities
+## Capabilities
 
-Defined v1 capability identifiers:
+Protocol v1 defines these capability identifiers:
 
-```txt
+```text
 vex.accounts
 vex.sessions
 vex.signTransaction
@@ -59,9 +61,9 @@ vex.signDigest
 vex.events
 ```
 
-A provider MUST declare static capabilities in `providerInfo.capabilities` and return negotiated capabilities from `vex_getCapabilities`.
+A provider declares its static capabilities in `providerInfo.capabilities` and returns the negotiated set from `vex_getCapabilities`.
 
-## 4. Capability negotiation
+## Capability negotiation
 
 Request:
 
@@ -88,11 +90,11 @@ Response:
 }
 ```
 
-The SDK rejects incompatible major versions and missing required capabilities before connect/sign flows continue.
+The client rejects an incompatible major version or a missing required capability before account or signing flows continue.
 
-## 5. Connect
+## Account access
 
-`vex_requestAccounts` is the interactive permission request.
+`vex_requestAccounts` is the interactive authorization request.
 
 Request:
 
@@ -119,11 +121,9 @@ Response:
 }
 ```
 
-The response is not an array and `sessionId` is mandatory.
-
-`chainId` in a response MUST be the 64-character Antelope chain ID. A request MAY use either that full ID or its `antelope:<32 hex characters>` CAIP-2 form. Wallets and clients MUST compare those two forms as the same chain when their prefixes match.
+`sessionId` is required. `chainId` in a response is the complete 64-character Vexanium chain ID. A request may use either the complete chain ID or its `antelope:<32 hex characters>` CAIP-2 scope. Clients compare the two forms by their shared chain prefix.
 
-`vex_getAccounts` is the silent restore/read path and returns:
+`vex_getAccounts` is the non-interactive restore/read path and returns:
 
 ```ts
 {
@@ -133,11 +133,9 @@ The response is not an array and `sessionId` is mandatory.
 }
 ```
 
-## 6. Signing paths
+## Exact transaction signing
 
-### Connected dApp / SessionKit
-
-`vex_signTransaction` signs the exact serialized Antelope transaction bytes resolved by SessionKit.
+`vex_signTransaction` signs the exact serialized Vexanium transaction supplied by the application or session layer.
 
 ```ts
 {
@@ -149,9 +147,9 @@ The response is not an array and `sessionId` is mandatory.
 }
 ```
 
-A wallet MUST NOT silently rebuild or mutate the transaction before signing.
+A wallet must not silently rebuild or alter the transaction before signing.
 
-`serializedTransaction` MUST contain non-empty, even-length hexadecimal bytes. `account` and `permission` MUST be valid Antelope names. A successful response contains at least one valid Antelope signature:
+`serializedTransaction` contains non-empty, even-length hexadecimal bytes. `account` and `permission` must be valid Antelope names. A successful response contains at least one valid signature:
 
 ```ts
 {
@@ -161,23 +159,25 @@ A wallet MUST NOT silently rebuild or mutate the transaction before signing.
 }
 ```
 
-### Portable Vexanium Signing Request
+## Vexanium Signing Requests
 
-`vex_signingRequest` is used for QR, deep-link, clipboard, or external wallet transport.
+`vex_signingRequest` is used for a request transported through a QR code, deep link, clipboard, or external wallet flow.
 
-Canonical Vexanium URI scheme:
+The canonical Vexanium URI scheme is:
 
-```txt
+```text
 vsr://...
 ```
 
-The payload format is compatible with WharfKit SigningRequest / ESR Revision 3. `esr://...` is accepted as interoperability input. The client validates either scheme with WharfKit and forwards the original URI without decoding, re-encoding, or replacing its scheme.
+The payload follows the compatible Antelope signing-request format used by existing ecosystem tooling. Compatible input using the established alternate URI scheme may be accepted for interoperability, while newly created Vexanium requests use `vsr:`.
+
+A successful signing-request response contains `signatures: string[]` and `broadcast: boolean`. Empty or malformed signature lists are rejected.
 
-A signing-request response MUST include `signatures: string[]` and `broadcast: boolean`. A client MUST reject an empty or malformed signature list.
+## Errors
 
-## 7. Standard errors
+Protocol v1 defines these provider error codes:
 
-```txt
+```text
 4001    USER_REJECTED
 4100    UNAUTHORIZED
 4200    UNSUPPORTED_METHOD
@@ -193,31 +193,45 @@ A signing-request response MUST include `signatures: string[]` and `broadcast: b
 -32603  INTERNAL_ERROR
 ```
 
-Errors MUST expose a numeric `code` and human-readable `message`. Optional `data` may provide structured context.
+Errors expose a numeric `code` and a human-readable `message`. Optional `data` may carry structured context.
+
+## Events
 
-## 8. Events
+Compatible providers may emit:
 
-```txt
+```text
 connect
 accountsChanged
 disconnect
 chainChanged
 message
 ```
 
-`connect` uses the canonical connect response shape. `accountsChanged` uses the canonical accounts response shape.
-
-## 9. Security boundary
-
-`DappMetadata` is display metadata only. Wallet permission state MUST bind to an authoritative transport/runtime origin, such as the browser extension sender origin. A wallet MUST NOT trust a dApp-supplied `origin` field as the permission boundary.
+`connect` uses the canonical connection response shape. `accountsChanged` uses the canonical accounts response shape.
 
-## 10. Discovery
+## Discovery
 
-A provider may be discovered through `window.vexanium` or Vexanium provider announcement events. A discovered provider MUST expose valid mandatory `providerInfo`; the SDK does not invent provider metadata.
+A provider may be exposed through `window.vexanium` or provider announcement events. Discovery uses:
 
-Discovery uses these window events:
-
-```txt
+```text
 vexanium:requestProvider
 vexanium:announceProvider
 ```
+
+A discovered provider must expose valid mandatory `providerInfo` before it is accepted.
+
+## Security
+
+`DappMetadata` is display metadata only. Wallet permission state must bind to an authoritative runtime or transport origin, such as the browser extension sender origin. A wallet must not use an origin supplied by application content as the permission boundary.
+
+Exact transaction signing must preserve the bytes approved by the application and must not substitute a rebuilt transaction after user approval.
+
+## Runtime
+
+The specification is transport-oriented and does not require a specific UI framework, storage implementation, or signing backend. Implementations may use browser extensions, mobile wallet bridges, embedded providers, or other trusted transports as long as the observable provider contract remains compatible.
+
+## License
+
+MIT License.
+
+Created by **Gilang Ramadan**. Copyright © 2026 PT WIND KRIPTOGRAFI TEKNOLOGI.