Precompile 0x…0803 unassigned; ws-origins for browser WebSocket clients

docs/contracts.md

@@ -77,13 +77,17 @@ at fixed addresses. `eth_getCode` on the static ones below returns empty
 (the werc20 precompile is the exception — `x/erc20` registers placeholder
 ERC-20 bytecode at its address so `extcodesize`-style "is this a contract"
 checks pass). `cosmos/evm`'s own precompiles occupy `0x…0100`–`0x…0807`;
-Konstellation's range starts at `0x…0900`.
+Konstellation's range starts at `0x…0900`. **Ten** addresses are active in
+genesis: `0x…0100`, `0x…0400`, `0x…0800`, `0x…0801`, `0x…0802`, `0x…0804`,
+`0x…0805`, `0x…0806`, `0x…0807`, `0x…0900`.
 
 | Precompile | Address | Notes |
 |---|---|---|
 | p256 (EIP-7212 / RIP-7212) | `0x0000000000000000000000000000000000000100` | secp256r1 signature verification, from `cosmos/evm`. What passkey / WebAuthn smart accounts need. |
 | bech32 | `0x…0400` | `cosmos/evm` |
-| staking, distribution, ICS20, vesting, bank, gov, slashing, ICS02 | `0x…0800`–`0x…0807` | `cosmos/evm` |
+| staking, distribution, ICS20 | `0x…0800`, `0x…0801`, `0x…0802` | `cosmos/evm` |
+| *(unassigned)* | `0x…0803` | Listed upstream as the "vesting" precompile address, but cosmos/evm v0.7.3 ships no implementation for it. **Not active** on Konstellation: a call to an active-but-unimplemented address panics in the keeper, so it is left out of the active set (konstellation PR #14). Nothing lives here. |
+| bank, gov, slashing, ICS02 | `0x…0804`, `0x…0805`, `0x…0806`, `0x…0807` | `cosmos/evm` |
 | WKASH (werc20 native precompile) | `0xD4949664cD82660AaE99bEdc034a0deA8A0bd517` | The native token as an ERC-20 interface, registered with `x/erc20` at genesis. Upstream default address, kept so tooling assumptions carry over. This is a precompile, not deployed bytecode — distinct from the `WKASH.sol` contract below. |
 | **ICompliance** | `0x0000000000000000000000000000000000000900` | Konstellation. Read-only view of the chain's compliance lists (below). |
 

docs/rpc-endpoints.md

@@ -46,6 +46,37 @@ testnet-1 is live — this table should link there rather than duplicate it.
 Not launched. Will follow the same shape as testnet-1 once genesis exists.
 Chain ID `5667`.
 
+## WebSocket from a browser (`eth_subscribe`)
+
+A dapp running **in a browser** that opens the WebSocket endpoint (for
+`eth_subscribe`, `newHeads`, log subscriptions — anything the HTTP endpoint
+cannot push) is subject to the node's Origin allow-list, `app.toml`
+`[json-rpc] ws-origins`. The list holds browser Origin **hosts** — no
+scheme, no port: the node compares the `Origin` header's hostname only, so
+`["localhost", "app.example.com"]` admits `http://localhost:5173` and
+`https://app.example.com` alike, and `["*"]` admits everything. `init`'s
+default is `["127.0.0.1", "localhost"]`.
+
+| `Origin` header | Result |
+|---|---|
+| host is in `ws-origins` | `101 Switching Protocols` — connected |
+| host is not in `ws-origins` | `403 Forbidden` |
+| absent (Node, Go, `curl`, `cast`, wallets' own RPC clients) | always admitted |
+
+So: a browser dapp needs its host in `ws-origins` **on the RPC node it talks
+to**. If you run the node, add the host and restart; if it is a public
+endpoint, ask its operator. Non-browser clients never hit this.
+
+:::note Older binaries reject every browser Origin
+On binaries before konstellation PR #14 the `ws-origins` array never
+reached the server: the SDK's config interception flattened the TOML array
+into one string (`[127.0.0.1 localhost]`), so every browser Origin got
+`403` while `curl` worked. Fixed in PR #14 (`cmd/konstellationd/cmd/flags.go`
+restores the array after interception; `--json-rpc.ws-origins a,b` on the
+command line always worked and still wins). If a node returns `403` for an
+Origin that is plainly in its list, it is on an old binary.
+:::
+
 ## Running your own RPC node
 
 Point clients at your own node instead of a shared endpoint. See

docs/troubleshooting.md

@@ -202,6 +202,25 @@ konstellationd query circuit disabled-list
 If something is on the list, it is there on purpose: watch the project's
 announcement channel rather than retrying.
 
+## WebSocket connection refused with `403` from a browser dapp
+
+**Symptom.** `eth_subscribe` (or any WebSocket use) from a page in a
+browser fails with HTTP `403` during the upgrade; the same endpoint works
+from `curl`, `cast`, Node or a wallet's own RPC client.
+
+**What it means.** The node's `app.toml` `[json-rpc] ws-origins` allow-list
+does not contain the page's host. It matches the `Origin` header's
+**hostname only** (no scheme, no port); requests with no `Origin` header
+are always admitted, which is why non-browser clients work. Fix: add the
+host to `ws-origins` on that node and restart, or ask the endpoint's
+operator to. Details on [RPC Endpoints](/rpc-endpoints#websocket-from-a-browser-eth_subscribe).
+
+**If the host is already in the list**, the node is on a binary older than
+konstellation PR #14, where the array was flattened to one string before
+it reached the server and every browser Origin got `403`. Upgrade the node;
+`--json-rpc.ws-origins a,b` on the `start` command line is the workaround
+until then.
+
 ## `panic: module account  does not exist: unknown address` on the first EVM tx after a restart
 
 **Symptom.** A node that was restarted on existing state panics on the first