qweb3 1.1.0__tar.gz

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
qweb3-1.1.0/LICENSE ADDED
@@ -0,0 +1,110 @@
1
+ # Quantova Licensing Overview
2
+
3
+ **Repository:** `qweb3.py` — Quantova Post-Quantum Web3 Client SDK (Python)
4
+
5
+ This repository contains software and documentation developed and maintained by Quantova Inc. This file serves as the authoritative licensing index for the contents of this repository and applies to all contents of this repository unless explicitly stated otherwise. It is published in alignment with the licensing standard of the wider Quantova technology stack.
6
+
7
+ ## Copyright and Ownership
8
+
9
+ © 2026 Quantova Inc. All rights reserved.
10
+
11
+ Quantova Inc is a company registered in Singapore and is the legal owner and steward of:
12
+
13
+ - The Quantova protocol
14
+ - The QRC20 network standards
15
+ - The Quantova Virtual Machine (QVM)
16
+ - The Provenance and Quantization Registry (PQR)
17
+ - Associated research, specifications, client libraries, and reference implementations
18
+
19
+ `qweb3.py` is the official Python client SDK for the Quantova network and forms part of this stack.
20
+
21
+ ## Primary License: Business Source License (BUSL-1.1)
22
+
23
+ Unless otherwise stated, all contents of this repository — including the SDK source code, reference implementations, examples, and documentation — are licensed under the Business Source License, version 1.1 (BUSL-1.1).
24
+
25
+ The full license text is included in this repository at:
26
+
27
+ ```
28
+ /LICENSE-BUSL-1.1
29
+ ```
30
+
31
+ The authoritative BUSL-1.1 license text may also be obtained from: https://mariadb.com/bsl11/
32
+
33
+ Key parameters for this repository:
34
+
35
+ - **Licensor:** Quantova Inc.
36
+ - **Licensed Work:** `qweb3.py` — Quantova Post-Quantum Web3 Client SDK, © 2026 Quantova Inc.
37
+ - **Change Date:** 2029-06-01 (or the fourth anniversary of the first public distribution of a given version, whichever comes first).
38
+ - **Change License:** Apache License, Version 2.0.
39
+
40
+ On the Change Date, each version of the Licensed Work converts automatically to the Change License.
41
+
42
+ ## What This Repository Contains
43
+
44
+ This repository provides the client-side developer SDK used to interact with the canonical Quantova network: post-quantum key generation and signing (Falcon, Dilithium, SPHINCS+), the `q_*` JSON-RPC client, the QVM contract layer (Solidity ABI encoding/decoding and event-log decoding), QNS `.q` name resolution, fee and gas estimation, batch requests, event hooks, a REST gateway client, and the `qweb3-cli` toolbelt. It does not contain Quantova consensus, runtime, or node implementation code.
45
+
46
+ ## Application and Integration Clarification
47
+
48
+ Building applications, wallets, services, dashboards, integrations, and developer tooling on top of this SDK that interact with the canonical Quantova network is explicitly permitted under the BUSL-1.1 license and does not constitute restricted "Production Use." Using this SDK to submit transactions, query state, manage keys, and operate infrastructure on the Quantova network does not create additional licensing obligations.
49
+
50
+ ## Validator and Node Operator Clarification
51
+
52
+ Running a validator node or full node on the canonical Quantova network, and using this SDK to support such operation, is explicitly permitted under the BUSL-1.1 license and does not constitute restricted "Production Use."
53
+
54
+ A formal clarification for validators, node operators, exchanges, custodians, and infrastructure providers is provided at:
55
+
56
+ ```
57
+ /docs/validators/licensing.md
58
+ ```
59
+
60
+ Participation in staking, consensus, block production, and transaction processing on the Quantova network does not create additional licensing obligations.
61
+
62
+ ## Restricted Use Under BUSL-1.1
63
+
64
+ The BUSL-1.1 license restricts use of the Licensed Work, together with Quantova consensus, runtime, and QVM code, to launch, operate, or market a competing blockchain network or distributed ledger that is not the canonical Quantova network. It further restricts offering the Licensed Work to third parties as a hosted or managed service, or otherwise using the Licensed Work to provide a commercial product or service that competes with the products or services of the Licensor.
65
+
66
+ This restriction applies to, but is not limited to:
67
+
68
+ - Independent or derivative mainnets
69
+ - Forks marketed as separate networks
70
+ - Networks intended to replace or compete with Quantova
71
+ - SDK distributions repackaged or offered as a competing managed service
72
+
73
+ Forking, modifying, or analyzing the code for testing, auditing, research, or contribution purposes is permitted.
74
+
75
+ ## Canonical Network Definition
76
+
77
+ For licensing and authorization purposes, the canonical Quantova network is defined by all of the following:
78
+
79
+ - Official signed source releases published by Quantova Inc
80
+ - A unique post-quantum genesis hash
81
+ - Signed runtime and protocol artifacts
82
+ - Post-quantum cryptographic signatures, including CRYSTALS-Dilithium and Falcon
83
+
84
+ Any network deployment that does not match these identifiers is not the Quantova network and is not authorized under the Quantova BUSL license.
85
+
86
+ ## Documentation and Specifications
87
+
88
+ Documentation, research materials, and protocol specifications included in this repository are licensed under BUSL-1.1 unless explicitly stated otherwise within the relevant file or directory. Documentation is provided for informational and technical reference purposes and reflects protocol behavior enforced by code.
89
+
90
+ ## Third-Party Software
91
+
92
+ This repository depends on third-party open-source software. Such components remain subject to their original licenses. This includes `requests` (Apache-2.0). Post-quantum signing additionally relies on Quantova's native post-quantum crypto backend, which is distributed separately under its own Quantova license terms. Where applicable, third-party license notices are provided in:
93
+
94
+ ```
95
+ /THIRD_PARTY_LICENSES.md
96
+ ```
97
+
98
+ or within dependency manifests (for example, `pyproject.toml`).
99
+
100
+ ## No Legal, Financial, or Regulatory Advice
101
+
102
+ Nothing in this repository, including documentation and specifications, constitutes legal, financial, or regulatory advice. Operators, validators, and users are responsible for ensuring compliance with applicable laws and regulations in their respective jurisdictions.
103
+
104
+ ## Institutional and Licensing Inquiries
105
+
106
+ Licensing, institutional, and regulatory inquiries relating to the Quantova technology stack should be directed through official Quantova channels published by Quantova Inc.
107
+
108
+ Protocol identity and licensing intent are cryptographically anchored at genesis via an immutable on-chain commitment.
109
+
110
+ © 2026 Quantova Inc
qweb3-1.1.0/PKG-INFO ADDED
@@ -0,0 +1,75 @@
1
+ Metadata-Version: 2.4
2
+ Name: qweb3
3
+ Version: 1.1.0
4
+ Summary: Quantova Post-Quantum Web3 Client SDK (Python)
5
+ Author: Quantova
6
+ License: Apache-2.0
7
+ Project-URL: Homepage, https://quantova.org
8
+ Keywords: quantova,web3,post-quantum,blockchain,qvm,dilithium,falcon,sphincs-plus,sdk
9
+ Requires-Python: >=3.8
10
+ Description-Content-Type: text/markdown
11
+ License-File: LICENSE
12
+ Requires-Dist: requests>=2.25
13
+ Requires-Dist: mnemonic>=0.20
14
+ Dynamic: license-file
15
+
16
+ # Qweb3.py
17
+
18
+ **Quantova Post-Quantum Web3 Client — Python SDK.** Connect to a
19
+ [Quantova](https://quantova.org) node, manage post-quantum accounts, sign and
20
+ broadcast transactions, and interact with QVM smart contracts from Python. The Python
21
+ counterpart of [qweb3.js](https://github.com/Quantova/Qweb3.js) and
22
+ [qweb3.rs](https://github.com/Quantova/qweb3.rs).
23
+
24
+ ## Quantum security
25
+ Quantova is a post-quantum Layer-1. Accounts use **NIST post-quantum signatures**
26
+ (**Falcon-512**, **SPHINCS+ SHAKE-128s**, **CRYSTALS-Dilithium2/ML-DSA-44**) with
27
+ **SHA3-256** — no ECDSA/secp256k1 — so they resist quantum attacks. Addresses are
28
+ **Bech32m `Q1...`**; the chain speaks **`q_*` JSON-RPC**.
29
+
30
+ ## Cross-SDK compatibility (byte-for-byte)
31
+ Accounts derive identically to qweb3.js and qweb3.rs, so **the same mnemonic yields the
32
+ same `Q1...` address** in all three SDKs:
33
+
34
+ - mnemonic -> 32-byte seed = substrate mini-secret
35
+ `PBKDF2-HMAC-SHA512(BIP-39 entropy, "mnemonic", 2048)[:32]` — *verified* equal to
36
+ qweb3.js (`"test test ... junk"` -> `4ca479f5...3b4709c`).
37
+ - address = `SHA3-256(public_key)[:20]` with byte 0 = `0x40`, Bech32m-encoded `Q1...`.
38
+ - keypairs use the **same post-quantum cores** as the node and qweb3.js: Falcon-512
39
+ (`ChaCha20Rng(seed)`), Dilithium2/ML-DSA-44 (`keygen_from_seed`), SPHINCS+ SHAKE-128s
40
+ (`blake2_256`-derived components).
41
+
42
+ ## Install
43
+ ```bash
44
+ pip install qweb3
45
+ ```
46
+
47
+ ## Post-quantum backend
48
+ The pure-Python package ships the full client (accounts, addresses, ABI, QNS, RPC,
49
+ fees, contracts) and the mnemonic/address derivation above. **Key generation and
50
+ signing require a post-quantum backend** exposing the falcon-wasm-style interface
51
+ (`<scheme>_pair_from_seed` / `_sign` / `_verify`). Register it once at startup:
52
+
53
+ ```python
54
+ import qweb3.crypto_backend as cb
55
+ cb.set_backend(my_pq_backend) # adapter over the Quantova PQ cores
56
+ ```
57
+
58
+ Any backend that produces the **same Falcon-512 / ML-DSA-44 / SLH-DSA-SHAKE-128s keys
59
+ from a seed** as qweb3.js keeps addresses and signatures cross-compatible. (The
60
+ recommended adapter wraps the same `fn-dsa` / `fips204` / `fips205` cores used by
61
+ qweb3.rs, so derivation stays byte-identical.)
62
+
63
+ ## Quick start
64
+ ```python
65
+ from qweb3 import QWeb3
66
+ q = QWeb3("https://rpc.quantova.org")
67
+ acct = q.wallet.import_mnemonic("test test ... junk") # -> same Q1... as qweb3.js/rs
68
+ print(q.rpc.get_balance(acct.address))
69
+ ```
70
+
71
+ ## Resources
72
+ - 🌐 https://quantova.org · 🔎 https://qvmscan.io · 💻 https://github.com/Quantova/Qweb3.py
73
+
74
+ ## License
75
+ BUSL-1.1 - (c) 2026 Quantova Inc. See LICENSE.
qweb3-1.1.0/README.md ADDED
@@ -0,0 +1,60 @@
1
+ # Qweb3.py
2
+
3
+ **Quantova Post-Quantum Web3 Client — Python SDK.** Connect to a
4
+ [Quantova](https://quantova.org) node, manage post-quantum accounts, sign and
5
+ broadcast transactions, and interact with QVM smart contracts from Python. The Python
6
+ counterpart of [qweb3.js](https://github.com/Quantova/Qweb3.js) and
7
+ [qweb3.rs](https://github.com/Quantova/qweb3.rs).
8
+
9
+ ## Quantum security
10
+ Quantova is a post-quantum Layer-1. Accounts use **NIST post-quantum signatures**
11
+ (**Falcon-512**, **SPHINCS+ SHAKE-128s**, **CRYSTALS-Dilithium2/ML-DSA-44**) with
12
+ **SHA3-256** — no ECDSA/secp256k1 — so they resist quantum attacks. Addresses are
13
+ **Bech32m `Q1...`**; the chain speaks **`q_*` JSON-RPC**.
14
+
15
+ ## Cross-SDK compatibility (byte-for-byte)
16
+ Accounts derive identically to qweb3.js and qweb3.rs, so **the same mnemonic yields the
17
+ same `Q1...` address** in all three SDKs:
18
+
19
+ - mnemonic -> 32-byte seed = substrate mini-secret
20
+ `PBKDF2-HMAC-SHA512(BIP-39 entropy, "mnemonic", 2048)[:32]` — *verified* equal to
21
+ qweb3.js (`"test test ... junk"` -> `4ca479f5...3b4709c`).
22
+ - address = `SHA3-256(public_key)[:20]` with byte 0 = `0x40`, Bech32m-encoded `Q1...`.
23
+ - keypairs use the **same post-quantum cores** as the node and qweb3.js: Falcon-512
24
+ (`ChaCha20Rng(seed)`), Dilithium2/ML-DSA-44 (`keygen_from_seed`), SPHINCS+ SHAKE-128s
25
+ (`blake2_256`-derived components).
26
+
27
+ ## Install
28
+ ```bash
29
+ pip install qweb3
30
+ ```
31
+
32
+ ## Post-quantum backend
33
+ The pure-Python package ships the full client (accounts, addresses, ABI, QNS, RPC,
34
+ fees, contracts) and the mnemonic/address derivation above. **Key generation and
35
+ signing require a post-quantum backend** exposing the falcon-wasm-style interface
36
+ (`<scheme>_pair_from_seed` / `_sign` / `_verify`). Register it once at startup:
37
+
38
+ ```python
39
+ import qweb3.crypto_backend as cb
40
+ cb.set_backend(my_pq_backend) # adapter over the Quantova PQ cores
41
+ ```
42
+
43
+ Any backend that produces the **same Falcon-512 / ML-DSA-44 / SLH-DSA-SHAKE-128s keys
44
+ from a seed** as qweb3.js keeps addresses and signatures cross-compatible. (The
45
+ recommended adapter wraps the same `fn-dsa` / `fips204` / `fips205` cores used by
46
+ qweb3.rs, so derivation stays byte-identical.)
47
+
48
+ ## Quick start
49
+ ```python
50
+ from qweb3 import QWeb3
51
+ q = QWeb3("https://rpc.quantova.org")
52
+ acct = q.wallet.import_mnemonic("test test ... junk") # -> same Q1... as qweb3.js/rs
53
+ print(q.rpc.get_balance(acct.address))
54
+ ```
55
+
56
+ ## Resources
57
+ - 🌐 https://quantova.org · 🔎 https://qvmscan.io · 💻 https://github.com/Quantova/Qweb3.py
58
+
59
+ ## License
60
+ BUSL-1.1 - (c) 2026 Quantova Inc. See LICENSE.
@@ -0,0 +1,26 @@
1
+ [build-system]
2
+ requires = ["setuptools>=64", "wheel"]
3
+ build-backend = "setuptools.build_meta"
4
+
5
+ [project]
6
+ name = "qweb3"
7
+ version = "1.1.0"
8
+ description = "Quantova Post-Quantum Web3 Client SDK (Python)"
9
+ readme = "README.md"
10
+ requires-python = ">=3.8"
11
+ license = { text = "Apache-2.0" }
12
+ keywords = ["quantova", "web3", "post-quantum", "blockchain", "qvm", "dilithium", "falcon", "sphincs-plus", "sdk"]
13
+ authors = [{ name = "Quantova" }]
14
+ dependencies = [
15
+ "requests>=2.25",
16
+ "mnemonic>=0.20",
17
+ ]
18
+
19
+ [project.urls]
20
+ Homepage = "https://quantova.org"
21
+
22
+ [project.scripts]
23
+ qweb3-cli = "qweb3.cli:main"
24
+
25
+ [tool.setuptools]
26
+ packages = ["qweb3"]
@@ -0,0 +1,107 @@
1
+ """qweb3 — Quantova Post-Quantum Web3 Client SDK (Python).
2
+
3
+ A synchronous client for the Quantova Layer-1 blockchain: post-quantum wallets
4
+ and signing (Falcon, Dilithium, SPHINCS+), the full ``q_*`` JSON-RPC namespace,
5
+ a QVM contract layer with ABI codec and event-log decoding, QNS ``.q`` name
6
+ resolution, dynamic fee/gas estimation, batch requests, real-time event hooks,
7
+ and REST-gateway access.
8
+
9
+ Quick start::
10
+
11
+ from qweb3 import QWeb3
12
+ q = QWeb3("http://127.0.0.1:9944", rest_url="http://127.0.0.1:8080")
13
+ block = q.rpc.block_number()
14
+ fees = q.fees.estimate()
15
+
16
+ Post-quantum signing requires Quantova's crypto backend; install it and call
17
+ ``qweb3.crypto_backend.set_backend(...)`` (see that module's docstring).
18
+ """
19
+
20
+ from . import abi, crypto_backend
21
+ from .abi import (
22
+ decode_function_result,
23
+ decode_parameters,
24
+ encode_function_call,
25
+ encode_parameters,
26
+ event_topic,
27
+ function_selector,
28
+ )
29
+ from .batch import BatchRequest, BatchResult
30
+ from .contract import QContract
31
+ from .errors import (
32
+ ConnectionErrorQ,
33
+ InvalidArgumentError,
34
+ QWeb3Error,
35
+ RpcError,
36
+ TransactionError,
37
+ )
38
+ from .fee import FeeOracle
39
+ from .hooks import EventHooks, TxTracker
40
+ from .qns import QNS
41
+ from .rest import QRestClient
42
+ from .rpc import QRpcClient
43
+ from .signer import QuantumSigner
44
+ from .utils import AddressUtils, FormatUtils, HexUtils, ValidationUtils
45
+ from .wallet import Account, QuantumWallet
46
+
47
+ __version__ = "1.1.0"
48
+
49
+
50
+ class QWeb3:
51
+ """High-level facade wiring the RPC client, wallet, fees, hooks, and helpers."""
52
+
53
+ def __init__(self, url: str = "http://127.0.0.1:9944", *,
54
+ rest_url: str = None, session=None) -> None:
55
+ self.url = url
56
+ self.rpc = QRpcClient(url, session=session)
57
+ self.rest = QRestClient(rest_url, session=session) if rest_url else None
58
+ self.wallet = QuantumWallet()
59
+ self.signer = QuantumSigner
60
+ self.abi = abi
61
+ self.fees = FeeOracle(rpc=self.rpc, rest_client=self.rest)
62
+ self.hooks = EventHooks(rpc=self.rpc, rest_client=self.rest)
63
+
64
+ def contract(self, abi_list, address: str) -> QContract:
65
+ return QContract(abi_list, address, rpc=self.rpc, wallet=self.wallet, rest_client=self.rest)
66
+
67
+ def qns(self, registry_address: str, **kwargs) -> QNS:
68
+ return QNS(registry_address, rpc=self.rpc, wallet=self.wallet,
69
+ rest_client=self.rest, **kwargs)
70
+
71
+ def batch(self) -> BatchRequest:
72
+ return BatchRequest(self.url)
73
+
74
+
75
+ __all__ = [
76
+ "QWeb3",
77
+ "QRpcClient",
78
+ "QRestClient",
79
+ "QuantumWallet",
80
+ "Account",
81
+ "QuantumSigner",
82
+ "QContract",
83
+ "QNS",
84
+ "BatchRequest",
85
+ "BatchResult",
86
+ "FeeOracle",
87
+ "EventHooks",
88
+ "TxTracker",
89
+ "AddressUtils",
90
+ "HexUtils",
91
+ "FormatUtils",
92
+ "ValidationUtils",
93
+ "QWeb3Error",
94
+ "ConnectionErrorQ",
95
+ "InvalidArgumentError",
96
+ "RpcError",
97
+ "TransactionError",
98
+ "abi",
99
+ "crypto_backend",
100
+ "function_selector",
101
+ "event_topic",
102
+ "encode_parameters",
103
+ "decode_parameters",
104
+ "encode_function_call",
105
+ "decode_function_result",
106
+ "__version__",
107
+ ]
@@ -0,0 +1,73 @@
1
+ """Pure-Python keccak-256 (Ethereum/Solidity padding, 0x01).
2
+
3
+ This is the default selector/topic hash used by the QVM ABI codec, which speaks
4
+ the standard Solidity ABI. It is dependency-free so the codec works out of the
5
+ box; it can be overridden via ``qweb3.abi.set_keccak`` (for example to use a
6
+ faster C implementation, or the hash provided by Quantova's crypto backend).
7
+
8
+ Note: this is keccak-256, not SHA3-256. They differ only in the padding byte.
9
+ Quantova hashes *transactions/state* with SHA3-256 (handled in the signing
10
+ layer); contract-call *selectors* use keccak-256, which is what this provides.
11
+ """
12
+
13
+ from typing import List
14
+
15
+ _RC = [
16
+ 0x0000000000000001, 0x0000000000008082, 0x800000000000808A, 0x8000000080008000,
17
+ 0x000000000000808B, 0x0000000080000001, 0x8000000080008081, 0x8000000000008009,
18
+ 0x000000000000008A, 0x0000000000000088, 0x0000000080008009, 0x000000008000000A,
19
+ 0x000000008000808B, 0x800000000000008B, 0x8000000000008089, 0x8000000000008003,
20
+ 0x8000000000008002, 0x8000000000000080, 0x000000000000800A, 0x800000008000000A,
21
+ 0x8000000080008081, 0x8000000000008080, 0x0000000080000001, 0x8000000080008008,
22
+ ]
23
+ _ROT = [
24
+ [0, 36, 3, 41, 18],
25
+ [1, 44, 10, 45, 2],
26
+ [62, 6, 43, 15, 61],
27
+ [28, 55, 25, 21, 56],
28
+ [27, 20, 39, 8, 14],
29
+ ]
30
+ _MASK = (1 << 64) - 1
31
+
32
+
33
+ def _rotl(x: int, n: int) -> int:
34
+ return ((x << n) | (x >> (64 - n))) & _MASK
35
+
36
+
37
+ def _keccak_f(s: List[List[int]]) -> None:
38
+ for rnd in range(24):
39
+ c = [s[x][0] ^ s[x][1] ^ s[x][2] ^ s[x][3] ^ s[x][4] for x in range(5)]
40
+ d = [c[(x + 4) % 5] ^ _rotl(c[(x + 1) % 5], 1) for x in range(5)]
41
+ for x in range(5):
42
+ for y in range(5):
43
+ s[x][y] ^= d[x]
44
+ b = [[0] * 5 for _ in range(5)]
45
+ for x in range(5):
46
+ for y in range(5):
47
+ b[y][(2 * x + 3 * y) % 5] = _rotl(s[x][y], _ROT[x][y])
48
+ for x in range(5):
49
+ for y in range(5):
50
+ s[x][y] = (b[x][y] ^ ((~b[(x + 1) % 5][y]) & b[(x + 2) % 5][y])) & _MASK
51
+ s[0][0] ^= _RC[rnd]
52
+
53
+
54
+ def keccak256(data: bytes) -> bytes:
55
+ """Return the 32-byte keccak-256 digest of ``data``."""
56
+ rate = 136 # bytes for keccak-256
57
+ msg = bytearray(data)
58
+ pad_len = rate - (len(msg) % rate)
59
+ msg += bytearray(pad_len)
60
+ msg[len(data)] ^= 0x01 # keccak padding (Ethereum/Solidity)
61
+ msg[-1] ^= 0x80
62
+
63
+ s = [[0] * 5 for _ in range(5)]
64
+ for off in range(0, len(msg), rate):
65
+ for i in range(rate // 8):
66
+ lane = int.from_bytes(msg[off + i * 8: off + i * 8 + 8], "little")
67
+ s[i % 5][i // 5] ^= lane
68
+ _keccak_f(s)
69
+
70
+ out = bytearray()
71
+ for i in range(4): # 4 lanes * 8 bytes = 32 bytes
72
+ out += (s[i % 5][i // 5]).to_bytes(8, "little")
73
+ return bytes(out)