@kassealhq/sdk 0.2.0 → 1.0.0

package/CHANGELOG.md

@@ -2,6 +2,93 @@
 
 All notable changes to `@kassealhq/sdk`. The versioning rules are in [STABILITY.md](STABILITY.md).
 
+## 1.0.0
+
+The first stable release: the public API is frozen under semantic versioning, as set out in
+[STABILITY.md](STABILITY.md).
+
+**Upgrading from 0.3.x**
+
+- Nothing breaks. Every 0.3.0 export is still exported with the same name, every 0.3.0 call keeps its parameters,
+  and a build without the new options produces the same transaction, byte for byte, as 0.3.0.
+- The string unions that describe a built transaction (`OutputRole`, `InputCellKind`, `SignatureKind`) have new
+  members. Code that switches over them exhaustively should keep a default branch.
+
+**Wallet partner tag**
+
+- Trade builds take an optional wallet partner tag: `partner: { partner, channel }` on `buildBuy`, `buildSell`,
+  `buildSwap` and `buildScriptSell`, and `partnerTag` on the synchronous shapes `buildBuy`, `buildSell`,
+  `buildSwapKasForTokens` and `buildSwapTokensForKas`. A wallet that embeds Kasseal trades in its own app passes its
+  partner id and channel 3 (`embedded`). See [docs/partner-tag.md](docs/partner-tag.md).
+- With a tag, the transaction's payload is the 6-byte tag (`4B 53 01`, partner id u16 big-endian, channel u8) and the
+  network fee covers its 6 bytes. Without one, the payload stays empty and every build is byte for byte as before.
+- New exports: `PARTNER_IDS`, `PARTNER_CHANNELS`, `encodePartnerTag`, `decodePartnerTag`, `decodePartnerTagHex`,
+  `isPartnerId`, `isPartnerChannel`, `tradePayload`, the format constants (`PARTNER_TAG_BYTES`, `PARTNER_TAG_VERSION`,
+  `PARTNER_TAG_MAGIC_0`, `PARTNER_TAG_MAGIC_1`) and the types `PartnerTag`, `PartnerId`, `PartnerChannel`, `PartnerKey`,
+  `PartnerChannelKey`, `PartnerOptions`.
+- Partners at release: KasWare (1), Kaspire (2), Kastle (3, reserved) and BraidSwap (1000, the first app partner;
+  its tag is `4B 53 01 03 E8 03`).
+- New guide for wallets, [docs/partner-tag.md](docs/partner-tag.md), and example `examples/partner-tag.ts`.
+- No change to the contract builds, their artifacts or any other builder.
+
+**Token locks**
+
+- The token-lock build is bundled: the lock program (`LOCK_H` `9f4eb229…0ac9`) and its factory (`FACTORY_H`
+  `481065e0…8f6b`), one build for mainnet and testnet-10, each file checked against its pinned SHA-256 at load
+  (`artifactManifest.lock`, `lockArtifactPaths`). The web entries load it as one chunk on first use.
+- Read and verify: `loadLockSet`, `lockProgramKind` (template-hash recognition, state left out), `decodeLockState`,
+  `encodeLockState`, `lockStateOfProgram`, `lockCellOf`, `lockTokenCellProblem`, `lockStateProblem`, and the
+  schedule: `lockVestedAt`, `lockClaimableAt`, `lockNextUnlock`, `lockSchedule`, `lockAmountAt`, `lockDueAt`,
+  `lockRemaining`, `lockEndOf`, `lockEndCapOf`, `lockDeposit`.
+- Create: `buildLockPrep` (the creator's factory cell) and `buildLockCreate` (the lock, its token cell, the creator's
+  rest), with `lockFactoryAddressOf` and `lockFactoryCellsOf` for factory cells an earlier prep left unspent. Claim:
+  `buildLockClaim` (anyone, no signature). Checks of a serialised create or claim: `checkLockCreateTx`,
+  `checkLockClaimTx`. The transactions are byte for byte the ones Kasseal's app builds.
+- Kasseal's lock rules (`assertLockAppRules`; at least 0.05 % of the supply, 7 days to 2 years, at most 100
+  releases, no back-dated schedule) apply in the builders; `lockMinDurationMsOf(network)` gives 7 days on mainnet and
+  10 minutes on testnet-10 for `minDurationMs`. The README separates them from what the contracts enforce.
+- New error codes: `LOCK_REFUSED` (`LockRefused`), `LOCK_CLAIM_NOT_DUE` (`LockClaimNotDue`), `LOCK_RULE`
+  (`LockRuleViolation`).
+- The type declarations no longer name output roles and input kinds of contracts the package does not ship.
+
+**Many heads in one request**
+
+- `fetchCurveHeads({ baseUrl, cells?, pool?, attempts?, fetch? }, ids)` reads the curve heads of many tokens through
+  `GET /v1/tokens/heads`, `CURVE_HEADS_MAX` (50) per request, in the order asked. A graduated token carries its pool's
+  state (`pool`, on by default) and a token that cannot be served its own `error`. A 429 or 503 is waited out as in
+  `createApiSources`. For routers, aggregators and portfolios that price many tokens: one request in place of one per
+  token. New exports: `fetchCurveHeads`, `CURVE_HEADS_MAX`, and the types `CurveHeadsOptions` and `CurveHeadsItem`.
+
+## 0.3.0
+
+**The creator window (new contract builds)**
+
+- New launch builds `v1-kasseal-mainnet-3` (mainnet) and `v1-kasseal-mainnet-3-tn10` (testnet-10). Their curve's `buy`
+  has the creator window: on a curve nothing has traded on, only a buy funded by the token's creator is valid until
+  the curve is 200 DAA (about 20 seconds) old. The creator's own first buy is therefore always first; after the first
+  trade, buys are unrestricted. The pool program is the same file as in the earlier builds, byte for byte.
+- Both builds of each network are bundled: tokens launched before keep trading on `v1-kasseal-mainnet-2` and
+  `v1-kasseal-mainnet-2-tn10`. The builders recognise a token's build from its curve or pool program, as before.
+- `buildBuy` sets the curve input's sequence to `CREATOR_WINDOW_DAA` (200) when the window applies to the buyer
+  (`curveBuySequence`; the creator, read from the first funding input, needs none). A buy submitted inside the window
+  is refused by the node and can be sent again once the window has passed.
+
+**API**
+
+- `BUILD_OF_NETWORK` now names each network's launch build (`v1-kasseal-mainnet-3`, `v1-kasseal-mainnet-3-tn10`).
+  New `BUILDS_OF_NETWORK` lists every build of a network, launch build first; `SUPPORTED_BUILDS` lists all four.
+- `createContext(preset, network, 'v1', build)` accepts either build of the network; the default is the launch build.
+  `createTxBuilder` accepts contexts of either.
+- New exports: `CREATOR_WINDOW_DAA`, `hasCreatorWindow`, `curveBuySequence`, `fundedByCreator`,
+  `V1_CREATOR_WINDOW_REVISION`, `V1_CREATOR_WINDOW_TWIN_REVISION`.
+- The per-network browser entries load both builds of their network and add `WEB_BUILDS`; `WEB_BUILD` is the launch
+  build.
+
+**What to do**
+
+- Code that compared `BUILD_OF_NETWORK` or `WEB_BUILD` with a token's build: use `BUILDS_OF_NETWORK` / `WEB_BUILDS`.
+- Code that builds its own curve buys without `buildBuy`: set the curve input's sequence as `curveBuySequence` returns.
+
 ## 0.2.0
 
 **Entry points**

package/README.md

@@ -13,11 +13,13 @@ The SDK gives you:
 - **Transaction builders** for curve buys and sells, pool swaps (including composable swap-and-deposit and
   script-owned sells), adding and removing liquidity, and fee payouts.
 - **Launch-proof verification**, so you can prove a token, its curve and its pool are genuine before you trade.
+- **Token locks**: decode and verify a lock, compute what it releases and when, build its creation and its claims.
 - **Submission helpers** for the races every UTXO venue has: build on the pending tip, retry without trading twice.
 - **Wallet adapters** for KasWare, Kastle and Kaspire.
 - **API types** for the public Kasseal REST API.
 
-Version 0.1.0 is a 0.x release: see [STABILITY.md](STABILITY.md) before you depend on it.
+Version 1.0 is the first stable release: its public API follows semantic versioning, as set out in
+[STABILITY.md](STABILITY.md).
 
 ## Install
 
@@ -115,13 +117,23 @@ The complete program, with the safe retry, is [examples/pool-buy.ts](examples/po
 
 ## Networks
 
-| Network | Network id | API base URL | Contract build | Status |
+| Network | Network id | API base URL | Contract builds | Status |
 |---|---|---|---|---|
-| Kaspa mainnet | `mainnet` | `https://app.kasseal.com/v1` | `v1-kasseal-mainnet-2` | Live |
-| Kaspa testnet-10 | `testnet-10` | `https://testnet.kasseal.com/v1` | `v1-kasseal-mainnet-2-tn10` | Live |
+| Kaspa mainnet | `mainnet` | `https://app.kasseal.com/v1` | `v1-kasseal-mainnet-3` (new launches), `v1-kasseal-mainnet-2` | Live |
+| Kaspa testnet-10 | `testnet-10` | `https://testnet.kasseal.com/v1` | `v1-kasseal-mainnet-3-tn10` (new launches), `v1-kasseal-mainnet-2-tn10` | Live |
 
-The testnet build mirrors the mainnet build: the same contract sources, with Kasseal's testnet wallet as the fee
-recipient. Template hashes for both are in [docs/contract-artifacts.md](docs/contract-artifacts.md).
+A token keeps the build it was launched on, and the SDK trades both: it recognises a token's build from its curve or
+pool program. The two builds share one pool program; the newer curve adds the creator window (below). Each testnet
+build mirrors its mainnet build: the same contract sources, with Kasseal's testnet wallet as the fee recipient.
+
+### The creator window
+
+On a curve of `v1-kasseal-mainnet-3` that nothing has traded on yet, only a buy funded by the token's creator (the
+transaction's first funding input pays from the creator's key) is valid until the curve is 200 DAA (about 20 seconds)
+old. Anyone else's first buy must carry that age on its curve input, and the network holds it back until then. Once
+anything has traded, buys are unrestricted. The builders do this for you: `buildBuy` sets the curve input's sequence
+to `CREATOR_WINDOW_DAA` when the window applies (`curveBuySequence`); a submit inside the window is refused by the
+node and can be sent again once the window has passed. `hasCreatorWindow(ctx.curve)` tells whether a curve has it. Template hashes for both are in [docs/contract-artifacts.md](docs/contract-artifacts.md).
 
 ## What a trade costs
 
@@ -144,6 +156,119 @@ recipient. Template hashes for both are in [docs/contract-artifacts.md](docs/con
 - **Units.** Token amounts are whole tokens (0 decimals). Curve trades are in whole lots (1,000 tokens on most
   tokens, 10,000 on tokens launched at high KAS prices). Pool KAS legs are whole multiples of 0.01 KAS.
 
+## Wallets: adding your partner tag
+
+Wallet partners' trades are recognised by a 6-byte partner tag in the transaction's payload: `4B 53 01`, the partner
+id (u16, big-endian), the channel (u8). Tagged trades are credited to the partner under its partner agreement with
+Kasseal. Partner ids are assigned by Kasseal.
+
+- **Connected trades** (channel 1, extension; channel 2, WalletConnect): the Kasseal website adds the tag. The wallet
+  only has to sign the transaction with its payload unchanged; it must never strip or rewrite the payload.
+- **In-wallet trades** (channel 3): a swap inside the wallet's own app adds the tag itself. Pass `partner` to
+  `buildBuy`, `buildSell`, `buildSwap` or `buildScriptSell` (or `partnerTag` to the synchronous shapes):
+
+```ts
+import { encodePartnerTag, decodePartnerTagHex, type PartnerTag } from '@kassealhq/sdk/web';
+
+const partner: PartnerTag = { partner: 1, channel: 3 };                 // your id, channel 3 (in-wallet)
+const built = await builder.buildSwap({ ...swap, partner });           // `swap`: the quickstart's parameters
+decodePartnerTagHex(JSON.parse(built.txJson).payload);                  // { partner: 1, channel: 3 }
+encodePartnerTag(partner);                                              // the 6 bytes, for your own builds
+```
+
+The full guide, with every builder, the hand-built payload and the checks, is
+[docs/partner-tag.md](docs/partner-tag.md).
+
+## Token locks
+
+A token lock holds KCC-20 tokens (or LP shares) for a fixed beneficiary and releases them on a fixed schedule. It is
+two covenants: the **lock** (lineage K, one per lock) and a stateless **lock factory** that creates it. One lock build
+serves mainnet and testnet-10 alike; it is bundled with the SDK and checked against its pinned SHA-256 like the trade
+builds.
+
+- **State** (140 bytes at offset 1): the token's covenant id, the beneficiary (a Schnorr key, scheme `0x00`, or a
+  script hash, scheme `0x03`), `total`, `claimed` (releases paid), `start`, `cliff`, `period` (Unix ms), `tranches`
+  N (1 to 100), `version` and `endCap`.
+- **Schedule.** Release k is due at `max(cliff, start + k × period)`. Tokens released by the first k releases:
+  `floor(k × total / N)`, so the remainder is spread one token at a time. The last release is due at
+  `lockEndOf(state)`.
+- **Deposit.** The lock holds exactly `N × 1.2 KAS + 1 KAS` (`lockDeposit(N)`): each release pays 1 KAS with the
+  tokens to the beneficiary and up to 0.2 KAS of network fee; the final release pays what is left to the beneficiary.
+  The lock's token cell carries 1 KAS more.
+
+**Read and verify.** `await loadLockSet()` gives the build (it loads the lock chunk on demand in the web entries).
+`lockProgramKind(set, program)` recognises a lock or factory program by its template hash, the state left out.
+`lockCellOf(set, cell)` re-derives a served lock cell from its own redeem script (template, well-formed state, K);
+`lockClaimableAt`, `lockNextUnlock`, `lockSchedule`, `lockVestedAt`, `lockRemaining` and `lockEndOf` compute the
+schedule exactly as the contract does. A covenant id is a Kasseal lock only if its genesis was authorised by a
+factory program through its `create` entry; the lock program alone does not prove that
+([explorers.md](docs/explorers.md)).
+
+**Create.** Two transactions, built together before either is signed (a txid does not depend on signatures):
+
+1. `buildLockPrep` funds the creator's factory cell (0.2 KAS) from the creator's KAS, with change back to the creator.
+2. `buildLockCreate` spends that factory cell, 1 to 3 of the creator's token cells and the prep's change into the
+   lock, the lock's token cell, the creator's rest (if any) and change. Send it once the prep is accepted.
+
+The creator must be a Schnorr P2PK address: the factory binds the creation to an input paying exactly the creator's
+script. The prep signs plain KAS inputs (`signBuiltWithKey` works); the create also signs the creator's token cells,
+which are P2SH slots: sign them through a wallet adapter, or with your own signer as described in
+[trading-bots.md](docs/trading-bots.md#7-signing-submitting-and-following-a-transaction).
+
+```ts
+import { buildLockCreate, buildLockPrep, loadLockSet, lockMinDurationMsOf, signBuiltWithKey } from '@kassealhq/sdk/node';
+
+const set = await loadLockSet();
+const prep = buildLockPrep({ set, creator, funding: kasUtxos });              // kasUtxos: the creator's FundingUtxo[]
+const change = { outpoint: { txid: prep.tx.txid, index: 1 }, amount: prep.built.outputs[1]!.value, spk: prep.built.outputs[1]!.spk, daaScore: 0n, address: creator };
+const lock = buildLockCreate({
+  set, creator, factory: { ...prep.factory, daaScore: 0n }, tokenCells,     // the creator's key-owned cells of the token
+  beneficiary: { kind: 'p2pk', xOnly: beneficiaryKey },
+  total: 1_000_000n, start: now, cliff: now, period: 30n * 86_400_000n, tranches: 4n, // four monthly releases
+  funding: [change], supply, now, minDurationMs: lockMinDurationMsOf('mainnet'),
+});
+// lock.lockId is K. Sign and send prep.tx, then lock.tx once the prep is accepted.
+```
+
+**Claim.** Anyone may claim; only the beneficiary is paid, and a claim has no signature. `buildLockClaim` pays every
+release vested at `now`, the claim's lock time in Unix ms. The network accepts a timestamp lock time only once the
+chain's past median time is above it (about two minutes behind the newest block), and rejects a claim with a later
+one: pass at most the past median time minus 1 (Kasseal's app uses the API's `nowMs` less 2 minutes). Nothing due
+throws `LockClaimNotDue` with `nextAt`. The final claim also pays the lock's remaining KAS to the beneficiary.
+
+```ts
+import { buildLockClaim, fromHex, lockCellOf, tokenStateFromJson } from '@kassealhq/sdk/node';
+
+const { nowMs, locks: [l] } = await (await fetch(`${API_BASE}/locks/${lockId}/cells`)).json();
+const c = l.lockCell;
+const lock = lockCellOf(set, { outpoint: c.outpoint, value: BigInt(c.amount), covenantId: c.covenantId, program: fromHex(c.redeemScript), daaScore: 0n });
+const t = l.tokenCell;
+const tCell = { kind: 'token', outpoint: t.outpoint, value: BigInt(t.amount), covenantId: t.covenantId, program: fromHex(t.redeemScript), state: tokenStateFromJson(t.state), daaScore: 0n } as const;
+const claim = buildLockClaim({ set, lock, tCell, now: BigInt(nowMs) - 120_000n });
+// claim.tx is complete: submit claim.tx.txJson as is.
+```
+
+Every builder re-checks its own transaction from its bytes before returning it (`checkLockCreateTx`,
+`checkLockClaimTx`, also exported for transactions you did not build) and refuses with `LockRefused` (`rule` says
+which). The beneficiary's `extend` (moving the schedule later) is not in this release.
+
+**Contract rules and Kasseal's rules.** The contracts pin the state, the deposit, the lock's token cell and the
+creation's layout; they know neither the token's supply nor the time of the creation. The builders add Kasseal's
+rules, the ones its app offers and its indexer counts a lock as locked by:
+
+| Rule | Contract | Builder (`buildLockCreate`, `checkLockCreateTx`) |
+|---|---|---|
+| Releases | 1 to 100 | the same |
+| Amount | 1 to 10^18 tokens, at least one per release | at least 0.05 % of `supply`, at most `supply` |
+| Shortest lock | none | the last release at least `minDurationMs` after `now`: 7 days by default (`LOCK_MIN_DURATION_MS`); `lockMinDurationMsOf('testnet-10')` is 10 minutes (`LOCK_MIN_DURATION_MS_TESTNET`) |
+| Longest lock | the end at most `endCap` (end + 5 years) | the last release at most 2 years after `now` (`LOCK_MAX_DURATION_MS`) |
+| Back-dated schedule | allowed | refused: the first release by the schedule (`start + period`) must be after `now` |
+| Beneficiary | any 32 bytes, scheme `0x00` or `0x03` | a valid x-only key, or a script that needs a signature (`keyLockedRedeem`; `allowAnyScript` to override) |
+
+The 7-day minimum is Kasseal's mainnet rule. For now Kasseal's app also offers 10-minute locks on mainnet, and its
+indexer counts them as locked; pass `minDurationMs: LOCK_MIN_DURATION_MS_TESTNET` to build one. That is a policy
+setting that may return to 7 days, not a contract rule.
+
 ## Browser
 
 ```js
@@ -213,7 +338,7 @@ await initWeb({ kaspa: { module: kaspa, wasm: new URL('./vendor/kaspa/kaspa_bg.w
 
 ## Integrity
 
-- Contract artifacts: only the two builds above are bundled. `dist/artifacts/manifest.json` lists each build's
+- Contract artifacts: only the builds above and the token-lock build are bundled. `dist/artifacts/manifest.json` lists each build's
   template hashes and the SHA-256 of every file; the same manifest is compiled into the code, and every file is
   checked before use. A missing, altered or unlisted file is refused (`ArtifactIntegrityError`).
 - Kaspa WASM SDK: rusty-kaspa v2.1.0, unmodified. The Node build is hashed before it is loaded; the web WASM is
@@ -235,6 +360,7 @@ instead of matching messages. `ERROR_CODES` lists them all; [docs/errors.md](doc
 | [Trading bots](docs/trading-bots.md) | Reading state, building, racing, retrying, rate limits |
 | [DEXs and routers](docs/dex-and-routers.md) | Composable swaps: what the pool checks, what it refuses, what you must guard |
 | [Wallets](docs/wallets.md) | Showing Kasseal tokens and signing with KasWare, Kastle and Kaspire |
+| [Partner tag](docs/partner-tag.md) | Wallets: adding your partner tag to the trades you build or sign |
 | [Explorers](docs/explorers.md) | Labelling Kasseal covenants and transactions, decoding state |
 | [Launch proof](docs/launch-proof.md) | What the proof verifies and how to run it |
 | [API](docs/api.md) | REST routes, the stream, rate limits, errors |

package/SECURITY.md

@@ -10,7 +10,7 @@ open a public issue, post on social media or discuss it in a public channel unti
 
 Please include:
 
-- what is affected: the SDK version, the contract build (`v1-kasseal-mainnet-2` or `v1-kasseal-mainnet-2-tn10`), the
+- what is affected: the SDK version, the contract build (`v1-kasseal-mainnet-3`, `v1-kasseal-mainnet-2` or a testnet-10 build), the
   API route, or the app page;
 - the steps to reproduce, or a proof of concept (testnet-10 only);
 - the impact as you understand it: whose funds, how much, under what conditions;
@@ -58,5 +58,6 @@ compromised user device or key.
 
 ## Supported versions
 
-Security fixes go into the latest 0.x release. A release with a security fix is announced in the
-[CHANGELOG](CHANGELOG.md), and affected versions are marked deprecated on npm. See [STABILITY.md](STABILITY.md).
+Security fixes go into the latest 1.x release; 0.x releases receive no further fixes. A release with a security fix
+is announced in the [CHANGELOG](CHANGELOG.md), and affected versions are marked deprecated on npm. See
+[STABILITY.md](STABILITY.md).

package/STABILITY.md

@@ -1,38 +1,51 @@
 # Stability and versioning
 
-`@kassealhq/sdk` follows [semantic versioning](https://semver.org). While the version is **0.x**, the rules are:
+`@kassealhq/sdk` follows [semantic versioning](https://semver.org). From version 1.0.0 the public API described
+below is frozen under the usual rules:
 
 | Release | May contain |
 |---|---|
-| Patch (`0.1.0` → `0.1.1`) | Bug fixes, security fixes and documentation. No change to any stable API below, and no change to the bytes of any transaction a builder produces for the same inputs, unless the old bytes were wrong |
-| Minor (`0.1.x` → `0.2.0`) | New features, and breaking changes to the API. Every breaking change is listed in the [CHANGELOG](CHANGELOG.md) with what to do |
+| Patch (`1.0.0` → `1.0.1`) | Bug fixes, security fixes and documentation. No change to the public API, and no change to the bytes of any transaction a builder produces for the same inputs, unless the old bytes were wrong |
+| Minor (`1.0.x` → `1.1.0`) | New features that add to the API without breaking it: new exports, new optional parameters and result fields, new contract builds, newly assigned partner ids. Existing calls keep working and, for the same inputs, keep producing the same bytes |
+| Major (`1.x` → `2.0.0`) | Breaking changes to the API. Every breaking change is listed in the [CHANGELOG](CHANGELOG.md) with what to do |
 
-Pin a minor version (`~0.1.0`) if you want only fixes. Version 1.0.0 will freeze the public API under the usual
-semver rules.
+Depend on `^1.0.0` to receive fixes and additive features, or pin a minor version (`~1.0.0`) if you want only fixes.
 
 **Safety fixes come first.** If a release fixes a way your users could lose funds, we may tighten a check in a patch
 release, so that a call which used to succeed now throws. A stricter check is never loosened in a patch. Versions
 with a safety issue are marked deprecated on npm, with the reason.
 
-## What is stable in 0.x
+## What is stable in 1.x
 
-Changes to these happen only in a minor release, listed in the CHANGELOG:
+These change only in a major release, listed in the CHANGELOG; additions to them come in minor releases:
 
 - **Quote math**: the results of the curve, pool, liquidity and slippage functions. They mirror the contracts
   exactly; a contract build never changes, so for a given build the numbers never change either.
 - **Error codes**: the `code` string of every error class in [docs/errors.md](docs/errors.md). A code is never reused
-  for a different meaning.
+  for a different meaning. New codes may be added in a minor release.
 - **The launch-proof verdicts**: `bound`, `unverified`, `invalid`, `malformed`, and what each means.
-- **The bundled contract builds**: `v1-kasseal-mainnet-2` and `v1-kasseal-mainnet-2-tn10`, their artifacts and
-  their hashes. A new contract build is added in a minor release; a bundled build is never modified.
+- **The bundled contract builds**: `v1-kasseal-mainnet-3`, `v1-kasseal-mainnet-2` and their testnet-10 builds
+  `v1-kasseal-mainnet-3-tn10`, `v1-kasseal-mainnet-2-tn10`, the token-lock build (lock and factory, one build for both
+  networks), their artifacts and their hashes. A new contract build is added in a minor release; a bundled build is
+  never modified or removed in 1.x.
+- **The wallet partner tag**: format version 1, 6 bytes (`4B 53 01`, partner id u16 big-endian, channel u8; see
+  [docs/partner-tag.md](docs/partner-tag.md)), the channels 1, 2 and 3, and every assigned partner id. An id or a
+  channel is never reused for a different meaning. A new format would get a new version byte and would not replace
+  version 1 in 1.x.
+- **Token lock builders**: `buildLockPrep`, `buildLockCreate`, `buildLockClaim`, the checks `checkLockCreateTx` and
+  `checkLockClaimTx`, the schedule maths and the lock state codec give the same results and the same bytes for the same
+  inputs. Kasseal's own lock rules (`assertLockAppRules`) may only be loosened in a minor release, never tightened
+  outside the safety policy above.
 - **Entry points**: `@kassealhq/sdk`, `@kassealhq/sdk/node`, `@kassealhq/sdk/web`, `@kassealhq/sdk/web/mainnet`,
   `@kassealhq/sdk/web/testnet-10`, `@kassealhq/sdk/web-lite/mainnet`, `@kassealhq/sdk/web-lite/testnet-10`.
+- **The exported builders, quotes, codecs and wallet adapters**: their names, parameters and result shapes.
 
 ## What may change in a minor release
 
-- Builder parameters and result shapes (with a CHANGELOG entry and a migration note).
-- Wallet adapter details, as the wallets themselves change.
-- The pinned Kaspa WASM SDK version.
+- New optional parameters and result fields, and new members of the string unions that describe transactions
+  (output roles, input kinds, signature kinds). Code that switches over such a union should keep a default branch.
+- Wallet adapter details that follow the wallets themselves, as long as the adapter interface stays the same.
+- The pinned Kaspa WASM SDK version, when a compatible upstream release is needed.
 - Helpers marked experimental in their documentation.
 
 ## What the SDK does not control

package/dist/artifacts/contracts/curve/v1/artifacts/v1-kasseal-mainnet-3/curve.ctor.standard-k103.json

@@ -0,0 +1,251 @@
+[
+ {
+  "kind": "bytes",
+  "value": [
+   0,
+   0,
+   0,
+   0,
+   0,
+   0,
+   0,
+   0,
+   0,
+   0,
+   0,
+   0,
+   0,
+   0,
+   0,
+   0,
+   0,
+   0,
+   0,
+   0,
+   0,
+   0,
+   0,
+   0,
+   0,
+   0,
+   0,
+   0,
+   0,
+   0,
+   0,
+   0
+  ]
+ },
+ {
+  "kind": "int",
+  "value": 0
+ },
+ {
+  "kind": "int",
+  "value": 0
+ },
+ {
+  "kind": "byte",
+  "value": 0
+ },
+ {
+  "kind": "int",
+  "value": 8240000
+ },
+ {
+  "kind": "int",
+  "value": 103
+ },
+ {
+  "kind": "int",
+  "value": 1000
+ },
+ {
+  "kind": "int",
+  "value": 800000
+ },
+ {
+  "kind": "int",
+  "value": 400000000
+ },
+ {
+  "kind": "int",
+  "value": 100
+ },
+ {
+  "kind": "bytes",
+  "value": [
+   0,
+   0,
+   32,
+   214,
+   240,
+   158,
+   13,
+   162,
+   15,
+   104,
+   158,
+   59,
+   17,
+   144,
+   5,
+   147,
+   254,
+   205,
+   236,
+   220,
+   136,
+   237,
+   129,
+   240,
+   19,
+   3,
+   28,
+   116,
+   155,
+   222,
+   146,
+   217,
+   40,
+   229,
+   116,
+   172
+  ]
+ },
+ {
+  "kind": "bytes",
+  "value": [
+   0,
+   0,
+   32,
+   34,
+   34,
+   34,
+   34,
+   34,
+   34,
+   34,
+   34,
+   34,
+   34,
+   34,
+   34,
+   34,
+   34,
+   34,
+   34,
+   34,
+   34,
+   34,
+   34,
+   34,
+   34,
+   34,
+   34,
+   34,
+   34,
+   34,
+   34,
+   34,
+   34,
+   34,
+   34,
+   172
+  ]
+ },
+ {
+  "kind": "bytes",
+  "value": [
+   151,
+   3,
+   17,
+   46,
+   230,
+   227,
+   85,
+   81,
+   7,
+   205,
+   22,
+   136,
+   88,
+   153,
+   43,
+   119,
+   211,
+   183,
+   79,
+   101,
+   82,
+   5,
+   178,
+   180,
+   99,
+   177,
+   249,
+   236,
+   46,
+   199,
+   60,
+   247
+  ]
+ },
+ {
+  "kind": "int",
+  "value": 1
+ },
+ {
+  "kind": "int",
+  "value": 3885
+ },
+ {
+  "kind": "bytes",
+  "value": [
+   146,
+   172,
+   215,
+   97,
+   80,
+   78,
+   79,
+   160,
+   90,
+   207,
+   112,
+   103,
+   94,
+   241,
+   174,
+   160,
+   198,
+   110,
+   250,
+   33,
+   38,
+   236,
+   92,
+   114,
+   110,
+   71,
+   121,
+   184,
+   174,
+   240,
+   84,
+   224
+  ]
+ },
+ {
+  "kind": "int",
+  "value": 1000000000
+ },
+ {
+  "kind": "int",
+  "value": 0
+ },
+ {
+  "kind": "int",
+  "value": 8000
+ }
+]