Skip to main content

2n20 creator tools

Connect your strategy software to a 2n20 vault on Hyperliquid. Use your existing project or start with the included Python example.

Give your coding agent the 2n20-setup skill, or run the 2n20 CLI yourself. Run setup on the computer or server that will operate your strategy. You receive an approval link to review with your creator wallet. Your private trading key stays on the strategy machine.

After approval, resume the same setup directory to verify trading access and get your strategy settings. You define and operate the strategy. The starter includes Hyperliquid candles, an educational band-breakout strategy, a replaceable limit chaser and execution reporting. It makes no profitability claim. The Python import is twon20.

Install

Use Python 3.10 or later on your strategy computer or server:

python3 -m venv .venv-2n20
source .venv-2n20/bin/activate
python -m pip --isolated install '2n20==0.4.1'
2n20 --version

You install the Hyperliquid SDK with the starter's separate runner dependency lock. The base CLI needs no execution SDK. See the release instructions to build from source or check release artifacts.

Start or connect a project

Generate a new project in a directory that does not exist:

2n20 init my-strategy --template hyperliquid-python

Follow the installation and paper-run commands that init prints. It copies the bundled template and records its version. It does not install dependencies, create keys or start trading. Inspect the template source before using it. Review future template changes before updating your generated project.

For an existing strategy, continue in its authorized project directory. Never search unrelated projects or read their credentials to discover access.

2n20 onboard --vault '<official vault page URL>' --json

Save the returned resumeCommand and approvalUrl. If you run setup on a VPS, open the link on your wallet computer. Review the prepared request and approve with your creator wallet. Opening the link does not authorize a transaction.

Then run the exact resume command with the same setup directory. Read the CLI's separate results for contract approval, HyperCore activation and funding. An unavailable check leaves access unverified.

Resume with the existing key after an interruption. For expired consent or a changed nonce, follow the CLI's same-key renewal instruction. Resolve a conflicting requested or approved key before continuing. Do not generate another key to bypass a failed check.

The CLI automatically retries temporary RPC and approval-link failures within a bounded budget, preserving the same key and public consent. If the handoff service remains unavailable, import the exact public consent file printed by the CLI into the vault's Step 2. Resume the same directory. Renewal creates a new public file and retains the earlier files and private key.

Use your coding agent

From your strategy project, install both guides for your coding agent:

2n20 skill install --agent codex

Use cursor, claude or hermes instead of codex for those agents. Codex installs into the project's .agents/skills, Cursor into .cursor/skills, and Claude Code into .claude/skills. Hermes uses ~/.hermes/skills or the configured HERMES_HOME. Reload the agent's skills after installation. Identical copies stay unchanged; conflicting local copies are preserved for your review.

Use 2n20-strategy to adapt an existing backtest or bot, or develop the starter before a vault exists. The guide keeps your signals, sizing and research tools, and helps add only the operating modules you need. For example:

Use 2n20-strategy to adapt this project's backtested strategy for Hyperliquid and a future 2n20 vault. Keep its signals and sizing. Use the starter feed and limit chaser where operating code is missing. Verify paper behavior first.

Use 2n20-setup when you have a vault. Give your agent the vault URL, project location and machine. It uses the CLI through authorized terminal access; you open the approval link and use your wallet. A project prepared before vault creation is the same existing project in Step 2.

The vault's copied requests select the setup skill's Step 2 or Step 3 instructions. The bundle retains both complete guides, including native multiple-choice questions, prior-answer reuse and continuation with the same key. Your agent can read the released files in the current conversation if skill discovery is unavailable. Upgrading the CLI does not replace an installed skill; preserve differing local copies and use the release linked in the request or export it to a new comparison directory.

For another client, export a portable guide:

2n20 skill export --name 2n20-strategy --directory ./strategy-guide
2n20 skill export --name 2n20-setup --directory ./setup-guide

Give the complete exported directory to the client, including SKILL.md and any references files. Execution requires its own authorized terminal and filesystem tools. No MCP server is required for the local coding-agent flow. See Agent skills for installation options.

After your project's read-only connection and paper checks pass, your agent reports those results with the retained key. The website completes Step 3 automatically. To report the checks yourself:

2n20 complete-setup --vault '<official vault page URL>' --directory '<retained setup directory>' --connection-checked --paper-checked --json

Use the flags only after both checks succeed. This sends a signed public setup report, never your private key or project files. It submits no blockchain transaction and does not enable live trading. Reporting can be retried from the same directory without replacing the key.

Keep setup and execution separate

Use setup, onboard, renew, config, status, check-consent, init, skill export and skill install without submitting trades or collateral transfers. Keep strategy.key private on the strategy machine. Public configuration names its path without embedding the key. Agents must never inspect, print, upload or commit private-key contents. The CLI sets ignore rules and restrictive file permissions before creating a key.

Use paper mode without a signing key. Read its results as simulated fills and P&L. For live execution, the starter uses the official Hyperliquid SDK with the approved trading key as signer and the verified trading account as account_address. It does not use the SDK's legacy vault_address.

Before a live test, choose the market, side, maximum notional, slippage and time limit. Authorize that plan as a separate action; key approval does not authorize orders. Check usable perpetual collateral, since spot USDC is a separate balance. The starter refuses insufficient margin, unavailable approval, conflicting account state and unsupported account modes. Read the starter README before considering a live plan. You decide whether to install and start a service.

Documentation and contributions

We maintain the CLI, skills and starter in this public repository. We keep the application and financial contracts in a separate private repository.

Metadata

Release files for 2n20 0.4.1

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for 2n20 0.4.1
File Size Uploaded
2n20-0.4.1.tar.gz 277.5 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for 2n20 0.4.1
File Interpreter ABI Platform
2n20-0.4.1-py3-none-any.whl Python 3 none any Details

Total release size: 492.5 kB

Release files / 2n20-0.4.1.tar.gz

Download URL 2n20-0.4.1.tar.gz
Size 277.5 kB
Tags Source
SHA-256 checksum
How to use checksums
299d7f83e00913518aff33494edca6f19b504b38a8b758bcadba3b76fefc8e56
BLAKE2b-256 checksum
How to use checksums
ed9baaf64d1965bac3e21db016693166faa6184f3257e00edf0d18a147226aa6
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.7

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 11, 2026.

Transparency log

Release files / 2n20-0.4.1-py3-none-any.whl

Download URL 2n20-0.4.1-py3-none-any.whl
Size 215.0 kB
Tags Python 3
SHA-256 checksum
How to use checksums
4d72891710a2053e3bee3d709a2ab06fa0cb82d135d679a195fed18005dea445
BLAKE2b-256 checksum
How to use checksums
ac6dd428cb70d54ba2f37dc3e8d5f7111fd09a749e44c3eb2c1a708a369c31d9
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.7

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 11, 2026.

Transparency log

Release history Release notifications | RSS feed

0.5.2

2 release files

0.5.1

2 release files

0.5.0

2 release files

0.4.3

2 release files

0.4.2

2 release files

This release

0.4.1 This release

2 release files

0.4.0

2 release files

0.3.6

2 release files

0.3.5

2 release files

0.3.4

2 release files

0.3.3

2 release files

0.3.2

2 release files

0.3.1

2 release files

0.2.0

2 release files

0.1.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page