2n20 0.1.0__tar.gz

2n20-0.1.0/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 2n20
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

2n20-0.1.0/MANIFEST.in

@@ -0,0 +1,8 @@
+include LICENSE README.md requirements-release.txt dependency-review.json
+recursive-include src/twon20 *.py *.json
+recursive-include tests *.py *.public.json
+include scripts/build_release.py
+prune .venv
+prune build
+prune dist
+global-exclude *.key *.pem .env .env.* config.json notes.txt

2n20-0.1.0/PKG-INFO

@@ -0,0 +1,145 @@
+Metadata-Version: 2.4
+Name: 2n20
+Version: 0.1.0
+Summary: Local trading-key setup and public connection checks for 2n20 creators
+Author: 2n20
+License-Expression: MIT
+Project-URL: Homepage, https://2n20.org
+Project-URL: Documentation, https://2n20.org/docs/quickstart
+Project-URL: Repository, https://github.com/2n20/2n20
+Classifier: Development Status :: 3 - Alpha
+Classifier: Environment :: Console
+Classifier: Programming Language :: Python :: 3
+Classifier: Programming Language :: Python :: 3 :: Only
+Classifier: Topic :: Utilities
+Requires-Python: >=3.10
+Description-Content-Type: text/markdown
+License-File: LICENSE
+Requires-Dist: annotated-types==0.8.0
+Requires-Dist: bitarray==3.11.0
+Requires-Dist: ckzg==2.1.8
+Requires-Dist: cytoolz==1.1.0
+Requires-Dist: eth-account==0.13.7
+Requires-Dist: eth-hash==0.8.0
+Requires-Dist: eth-keyfile==0.8.1
+Requires-Dist: eth-keys==0.8.0
+Requires-Dist: eth-rlp==3.0.0
+Requires-Dist: eth-typing==6.0.0
+Requires-Dist: eth-utils==6.0.0
+Requires-Dist: eth_abi==6.0.0
+Requires-Dist: hexbytes==2.0.0
+Requires-Dist: parsimonious==0.10.0
+Requires-Dist: pycryptodome==3.23.0
+Requires-Dist: pydantic==2.13.5
+Requires-Dist: pydantic_core==2.46.5
+Requires-Dist: regex==2026.9.10
+Requires-Dist: rlp==5.0.0
+Requires-Dist: toolz==1.1.0
+Requires-Dist: typing-inspection==0.4.4
+Requires-Dist: typing_extensions==4.16.0
+Dynamic: license-file
+
+# 2n20 creator setup
+
+The official 2n20 CLI prepares trading-key consent on the computer or server
+where your existing strategy runs. It supplies public account configuration
+and read-only checks. You supply and run your own strategy in any language.
+
+Requires Python 3.10 or later on Linux, macOS or WSL. Run commands in your
+strategy's working directory with its Python environment activated.
+
+Copy the setup command from Step 2 of your vault page:
+
+```sh
+2n20 setup --vault 'https://2n20.org/vaults/<your-vault-address>?network=mainnet'
+```
+
+The CLI verifies the chain, factory, deployed contract code, vault bindings,
+trading-account bindings, consent capability and next approval nonce from
+public contract reads. This release bundles the currently supported HyperEVM
+mainnet deployment. Other networks and unsupported deployments fail closed.
+Vault URLs can select only a vault address and network. They cannot override
+RPC endpoints or supply an approval contract, trading account or nonce.
+
+Setup creates a new directory with mode `700` under your current working
+directory. Use `--output <new-directory>` to choose its name. The parent must
+already exist. Setup never reuses an existing output directory.
+
+- `strategy.key`: your new private trading key, mode `600`. Keep it only on
+  your strategy machine. Never paste, import, upload, commit or log this file.
+- `consent.public.json`: a public signature, trading-key address, vault,
+  approval contract, nonce and expiry. Import or paste only this file into
+  Step 2 and approve it with your creator wallet.
+- `setup.public.json`: public recovery metadata used by `renew`.
+- `strategy.public.json`: public account settings for your existing strategy.
+
+Keep the directory and key when a network read fails. If consent expires
+(after one hour), or another approval changes its nonce, run on that same
+strategy machine:
+
+```sh
+2n20 renew --directory ./<your-setup-directory>
+```
+
+Renew retains the existing private key and writes a new uniquely named
+`consent.<time>-<random>.public.json`. Import that new public file. If the key
+has already been used, create a fresh setup in a new directory. Existing keys
+and files are never replaced. The app and contract recheck nonce and expiry
+when you approve.
+
+After Step 2 confirms trading access, get the public settings for Step 3:
+
+```sh
+2n20 config --vault 'https://2n20.org/vaults/<your-vault-address>?network=mainnet'
+2n20 status --vault 'https://2n20.org/vaults/<your-vault-address>?network=mainnet'
+```
+
+Use `tradingAccount` as your strategy's Hyperliquid account address. It is
+separate from the `vault` holding shares and the `approvalContract` your
+creator wallet calls. Load the private key locally using your strategy's own
+key configuration. The CLI does not load your existing strategy's secrets.
+
+Status checks the current public key approval, account binding and funding.
+Missing or inconsistent public evidence never counts as trading readiness.
+Exit code `0` means public trading access was verified, `2` means it is
+pending or unverified, and `1` means verification could not complete. This
+check does not prove your strategy is running. Run its own connection check
+before starting it. These commands submit no transactions, move no collateral
+and place no orders. Setup does not depend on temporary Hyperliquid balance or
+funding API availability.
+
+To check a public consent before importing it:
+
+```sh
+2n20 check-consent --vault 'https://2n20.org/vaults/<your-vault-address>?network=mainnet' --consent ./<your-setup-directory>/consent.public.json
+```
+
+## Reproducible development and release
+
+`requirements-release.txt` contains the reviewed, fully pinned build and
+runtime graph with registry SHA-256 hashes. `dependency-review.json` records
+its registry publication dates. All third-party release files were at least
+14 days old when reviewed on October 3, 2026. The wheel also pins the complete
+runtime graph to retain these reviewed versions for ordinary installs.
+The only underlying runtime library is `eth-account` and its dependencies;
+Hyperliquid's SDK is not required.
+
+```sh
+python3 -m venv .venv
+.venv/bin/python -m pip install --require-hashes -r requirements-release.txt
+PYTHONPATH=src .venv/bin/python -m unittest discover -s tests -v
+SOURCE_DATE_EPOCH=1790985600 .venv/bin/python scripts/build_release.py
+```
+
+The release script calls standard `python -m build --no-isolation`, verifies
+archive paths, and normalizes the source archive ownership, timestamps and
+gzip header. Keep `SOURCE_DATE_EPOCH` fixed for a release. Repeated builds from
+the same source and reviewed environment produce identical wheel and source
+archive bytes. Use `--outdir <directory>` to compare independent builds.
+
+Release trust anchors are copied from the repository's reviewed active
+`deployments/development.json`, never fetched as authority from a website.
+A supported deployment change requires reviewing and releasing the package.
+Publishing uses GitHub Actions OIDC Trusted Publishing with dedicated PyPI
+and TestPyPI environments, not stored API tokens. Maintainer release steps
+and publisher identities are in the repository operations runbook.

2n20-0.1.0/README.md

@@ -0,0 +1,104 @@
+# 2n20 creator setup
+
+The official 2n20 CLI prepares trading-key consent on the computer or server
+where your existing strategy runs. It supplies public account configuration
+and read-only checks. You supply and run your own strategy in any language.
+
+Requires Python 3.10 or later on Linux, macOS or WSL. Run commands in your
+strategy's working directory with its Python environment activated.
+
+Copy the setup command from Step 2 of your vault page:
+
+```sh
+2n20 setup --vault 'https://2n20.org/vaults/<your-vault-address>?network=mainnet'
+```
+
+The CLI verifies the chain, factory, deployed contract code, vault bindings,
+trading-account bindings, consent capability and next approval nonce from
+public contract reads. This release bundles the currently supported HyperEVM
+mainnet deployment. Other networks and unsupported deployments fail closed.
+Vault URLs can select only a vault address and network. They cannot override
+RPC endpoints or supply an approval contract, trading account or nonce.
+
+Setup creates a new directory with mode `700` under your current working
+directory. Use `--output <new-directory>` to choose its name. The parent must
+already exist. Setup never reuses an existing output directory.
+
+- `strategy.key`: your new private trading key, mode `600`. Keep it only on
+  your strategy machine. Never paste, import, upload, commit or log this file.
+- `consent.public.json`: a public signature, trading-key address, vault,
+  approval contract, nonce and expiry. Import or paste only this file into
+  Step 2 and approve it with your creator wallet.
+- `setup.public.json`: public recovery metadata used by `renew`.
+- `strategy.public.json`: public account settings for your existing strategy.
+
+Keep the directory and key when a network read fails. If consent expires
+(after one hour), or another approval changes its nonce, run on that same
+strategy machine:
+
+```sh
+2n20 renew --directory ./<your-setup-directory>
+```
+
+Renew retains the existing private key and writes a new uniquely named
+`consent.<time>-<random>.public.json`. Import that new public file. If the key
+has already been used, create a fresh setup in a new directory. Existing keys
+and files are never replaced. The app and contract recheck nonce and expiry
+when you approve.
+
+After Step 2 confirms trading access, get the public settings for Step 3:
+
+```sh
+2n20 config --vault 'https://2n20.org/vaults/<your-vault-address>?network=mainnet'
+2n20 status --vault 'https://2n20.org/vaults/<your-vault-address>?network=mainnet'
+```
+
+Use `tradingAccount` as your strategy's Hyperliquid account address. It is
+separate from the `vault` holding shares and the `approvalContract` your
+creator wallet calls. Load the private key locally using your strategy's own
+key configuration. The CLI does not load your existing strategy's secrets.
+
+Status checks the current public key approval, account binding and funding.
+Missing or inconsistent public evidence never counts as trading readiness.
+Exit code `0` means public trading access was verified, `2` means it is
+pending or unverified, and `1` means verification could not complete. This
+check does not prove your strategy is running. Run its own connection check
+before starting it. These commands submit no transactions, move no collateral
+and place no orders. Setup does not depend on temporary Hyperliquid balance or
+funding API availability.
+
+To check a public consent before importing it:
+
+```sh
+2n20 check-consent --vault 'https://2n20.org/vaults/<your-vault-address>?network=mainnet' --consent ./<your-setup-directory>/consent.public.json
+```
+
+## Reproducible development and release
+
+`requirements-release.txt` contains the reviewed, fully pinned build and
+runtime graph with registry SHA-256 hashes. `dependency-review.json` records
+its registry publication dates. All third-party release files were at least
+14 days old when reviewed on October 3, 2026. The wheel also pins the complete
+runtime graph to retain these reviewed versions for ordinary installs.
+The only underlying runtime library is `eth-account` and its dependencies;
+Hyperliquid's SDK is not required.
+
+```sh
+python3 -m venv .venv
+.venv/bin/python -m pip install --require-hashes -r requirements-release.txt
+PYTHONPATH=src .venv/bin/python -m unittest discover -s tests -v
+SOURCE_DATE_EPOCH=1790985600 .venv/bin/python scripts/build_release.py
+```
+
+The release script calls standard `python -m build --no-isolation`, verifies
+archive paths, and normalizes the source archive ownership, timestamps and
+gzip header. Keep `SOURCE_DATE_EPOCH` fixed for a release. Repeated builds from
+the same source and reviewed environment produce identical wheel and source
+archive bytes. Use `--outdir <directory>` to compare independent builds.
+
+Release trust anchors are copied from the repository's reviewed active
+`deployments/development.json`, never fetched as authority from a website.
+A supported deployment change requires reviewing and releasing the package.
+Publishing uses GitHub Actions OIDC Trusted Publishing with dedicated PyPI
+and TestPyPI environments, not stored API tokens. Maintainer release steps
+and publisher identities are in the repository operations runbook.