On July 30, 2026, a weak random-number bug in Coldcard firmware let attackers drain more than $116 million in bitcoin. Two months later, a different kind of risk made headlines: mining pool concentration. Foundry USA and AntPool alone now mine 44.6% of every block, and the top four pools control close to 70% of total hashrate, according to pool-tracking data from Spark Research. Stratum V2, the rewritten mining protocol that lets individual miners pick their own transactions instead of trusting a pool operator to do it for them, is the main technical answer to that problem. This tutorial walks through moving an existing ASIC from Stratum V1 to Stratum V2 using the official Stratum Reference Implementation (SRI), step by step, with real configuration files you can copy.

Why Bitcoin Mining Needs Stratum V2 Now

Under the original Stratum V1 protocol, a mining pool builds the block template and simply hands workers a hash to solve. The miner never sees which transactions went into the block, and has no way to object if the pool drops certain transactions or reorders fee priority. That design worked fine when hashrate was spread across thousands of small operators. It works less well now that Bitcoin’s network hashrate sits around 940 EH/s, down about 12% from the all-time high of roughly 1,066 EH/s set in December 2025, and is increasingly concentrated behind a handful of pool operators.

Stratum V2 fixes the structural problem rather than the symptom. Every connection runs over the Noise protocol, so traffic between a miner and a pool is encrypted and authenticated by default, closing off a class of man-in-the-middle attacks that plagued Stratum V1 deployments. The bigger change is Job Declaration: a miner (or a declarator acting on their behalf) can propose its own transaction set and send only the resulting block header to the pool, so the pool can no longer unilaterally censor or reorder transactions. On June 25, 2026, GoMining and DEMAND Pool (DMND) mined block 955,318 using Job Declaration in production, which is the clearest evidence so far that the feature works outside a lab.

The timing matters because of what has already happened without it. A two-block chain reorganization in March 2026 was read by several analysts as a sign that one pool, Foundry USA, controlled enough hashrate to produce rare, back-to-back blocks on its own. By September 2026, Bitcoin had logged a third reorg in a single month, prompting renewed scrutiny of pool concentration. None of this proves malicious behavior by any single pool, but it does mean more of Bitcoin’s block production than most miners would like sits behind a small number of operators. Job Declaration does not fix mining centralization by itself. It does take transaction selection, one specific point of control, out of the pool’s hands and puts it back with the miner.

How Stratum V2 Is Actually Structured

Stratum V2 is not one monolithic protocol. The specification splits the work into four sub-protocols, and knowing which one does what makes the rest of this tutorial easier to follow. The Mining Protocol is the direct replacement for Stratum V1: it carries work assignments and share submissions between a miner and whatever it is connected to, now wrapped in the Noise encryption layer. The Template Distribution Protocol runs between a Bitcoin full node and whatever builds block templates, handing over the raw ingredients, current block height, previous block hash, and available transactions, that a template needs. The Job Negotiation Protocol, commonly called Job Declaration in pool documentation, is where a miner proposes a specific transaction set and the pool either accepts it or responds with its own. A fourth piece, the Job Distribution Protocol, pushes an agreed-upon job out to the actual hashing hardware once negotiation finishes.

The practical takeaway is that “running Stratum V2” can mean very different things depending on which of these four pieces you deploy. The Translator Proxy in Steps 3 through 6 of this tutorial only touches the Mining Protocol: it upgrades your connection’s encryption and framing, nothing more. Getting the actual decentralization benefit, control over which transactions make it into your proposed block, requires the Job Negotiation Protocol as well, which is why Step 7 treats the Job Declarator Client as a separate, optional layer rather than bundling it into the basic setup. Pools can and do implement these pieces independently, which explains why a pool can legitimately claim “Stratum V2 support” while only running the Mining Protocol’s encrypted transport and nothing on the negotiation side.

Prerequisites: Hardware, Software, and Versions

Gather these before starting. Version numbers below reflect the current Stratum Reference Implementation releases as of early October 2026.

  • A small always-on Linux host to run the proxy: a Raspberry Pi 4 or 5, an old laptop, or a $5/month VPS all work. Ubuntu 22.04/24.04 LTS or Debian 12 recommended.
  • Rust toolchain 1.75 or newer, only needed if building from source instead of using prebuilt binaries.
  • stratum protocol library, version 1.12.0, released September 17, 2026.
  • sv2-apps, version 0.8.0, the runnable package containing the Translator Proxy, Job Declarator Client, Job Declaration Server, and pool-side applications, also released September 17, 2026.
  • An ASIC currently mining over Stratum V1 (most stock Bitmain and MicroBT firmware, Braiins OS+, or a Bitaxe board). Native SV2 firmware is a separate, optional path covered below.
  • An account with an SV2-native pool. Braiins Pool pioneered the protocol and runs full Job Declaration support in production. DEMAND Pool (DMND) is the other confirmed native implementation. ckpool’s source gained Stratum V2 support on July 31, 2026, but confirm your specific ckpool deployment has it enabled before relying on it.
  • Docker 24 or newer and Docker Compose v2, optional, for the containerized setup in Step 8.
  • Router or firewall access to open one outbound TCP connection.
  • 60 to 90 minutes. An experienced operator with binaries already downloaded can do the translator-only path in 15 to 30 minutes. A first attempt with firmware checks and testing runs longer.

One clarification worth making before you start: OCEAN is not a Stratum V2 pool. It uses a separate protocol called DATUM that also gives miners control over block templates, but it is architecturally distinct from SV2 and not compatible with the SRI tools in this tutorial.

Step 1: Pick an SV2-Compatible Pool

Not every pool that says it “supports” Stratum V2 actually runs Job Declaration in production. Seven major pools, representing roughly 75% of global hashrate, including Foundry, AntPool, F2Pool, and SpiderPool, joined the Stratum V2 Working Group in May 2026. Working group membership means they are testing and contributing code. It does not mean you can point an ASIC at their public endpoint and get Job Declaration today. As of late 2026, independent trackers still count only two pools, Braiins Pool and DEMAND, as full native SV2 implementations with Job Declaration enabled for public miners.

PoolNative Stratum V2Job DeclarationStatus as of October 2026
Braiins PoolYesYesProtocol originator, full production support
DEMAND (DMND)YesYesFirst pool built entirely around SV2, mined block 955,318 via Job Declaration on June 25, 2026
ckpool / solo ckpoolSource-level, added July 31, 2026Reported, not independently confirmedVerify your specific deployment before relying on it
OCEANNoUses separate DATUM protocol, not SV2Do not expect SRI tools to work here
Foundry, AntPool, F2Pool, SpiderPool, MARA, and othersWorking Group members since May 2026No public native support confirmedEncrypted transport only, in some deployments

For this tutorial, register an account with Braiins Pool or DEMAND and generate a worker name before moving on. You will need the pool’s SV2 endpoint hostname, port, and your worker credentials in Step 4.

Step 2: Check Your ASIC’s Firmware Path

There are three distinct ways to get an ASIC onto Stratum V2, and conflating them is the single most common mistake in this migration.

  • SV1 ASIC plus Translator Proxy. The most common path. Your ASIC keeps its existing Stratum V1 firmware and connects to a local proxy that speaks SV2 to the pool on its behalf. No firmware change required. This is what most of this tutorial covers.
  • Native SV2 firmware. Some Braiins OS+ builds and other vendor firmware implement the SV2 protocol directly on the ASIC. Check your exact miner model and firmware release notes. The Translator Proxy is unnecessary if your firmware already speaks SV2 natively.
  • Bitaxe or other open hardware. Compatibility depends on the specific board revision and firmware branch. Some community firmware builds include SV2 client functionality, but stock firmware generally does not.

If you are not sure which category your hardware falls into, assume the Translator Proxy path. It is the safest default and does not touch your ASIC’s firmware at all, which matters given that a firmware bug is exactly what caused the Coldcard incident earlier this year on a different class of device.

Step 3: Install the SRI Translator Proxy

On your proxy host, install the Rust toolchain if you plan to build from source, or download the prebuilt release binary for your architecture from the sv2-apps GitHub releases page. Building from source is slower but lets you verify exactly what you are running.

git clone https://github.com/stratum-mining/sv2-apps.git
cd sv2-apps
git checkout v0.8.0
cargo build --release -p translator_sv2

# Binary will be at:
# ./target/release/translator_sv2

A full build on a Raspberry Pi 4 can take 15 to 20 minutes. On a modern VPS or laptop expect two to five minutes. If you downloaded a prebuilt binary instead, skip straight to making it executable and move on to configuration.

Step 4: Configure the Translator Proxy

The Translator Proxy needs two things: a local Stratum V1 listener for your ASIC to connect to, and an upstream Stratum V2 pool connection with your credentials. Create a configuration file named tproxy-config.toml.

[upstream]
pool_address = "stratum.braiinspool.com"
pool_port = 3336
authority_pubkey = "9auqWEzQDVyd2oe1JVGFLrpqYkYB9VEENSNomaD90Xa2"
pool_user = "yourusername.worker1"

[downstream]
listen_address = "0.0.0.0"
listen_port = 3333
difficulty = "auto"

[logging]
level = "info"
file = "/var/log/translator_sv2.log"

Replace the pool address, port, and authority public key with the values from your pool’s SV2 connection documentation, and swap in your own worker name. The authority_pubkey field is what lets the proxy verify it is talking to the real pool over the encrypted Noise connection rather than an intercepted endpoint, so copy it exactly from the pool’s official docs rather than from a forum post.

Step 5: Point Your ASIC at the Local Proxy

Start the proxy, then log into your ASIC’s web interface and change its pool URL from the pool’s direct address to your proxy host’s address and port.

# Start the proxy
./translator_sv2 -c tproxy-config.toml

# In the ASIC's pool configuration, set:
# Pool URL:  stratum+tcp://192.168.1.50:3333
# Worker:    yourusername.worker1
# Password:  x

Use the proxy host’s LAN IP address, not localhost, since the ASIC is a separate device on the network. Keep the worker name and password format identical to what the pool expects. The proxy passes these through without altering them.

Step 6: Confirm the Handshake and First Shares

Watch the proxy log for a successful Noise handshake and the first accepted share. A healthy startup looks like this:

[2026-10-02T14:02:11Z INFO] Noise handshake established with upstream pool
[2026-10-02T14:02:11Z INFO] Channel opened, channel_id=4471
[2026-10-02T14:02:14Z INFO] Downstream connection from 192.168.1.112:51022
[2026-10-02T14:02:15Z INFO] New job received, job_id=889213
[2026-10-02T14:03:02Z INFO] Share accepted, difficulty=65536, worker=yourusername.worker1

Give it five to ten minutes, then check your pool dashboard. Hashrate reported by the pool should be within a reasonable margin of what your ASIC’s own web interface reports locally. A large, persistent gap between the two numbers almost always means shares are being rejected somewhere between the proxy and the pool, which is covered in the troubleshooting section below.

Step 7: Add the Job Declarator Client (Optional, Advanced)

The Translator Proxy alone gets you encrypted transport and basic SV2 connectivity, but it does not give you transaction selection. For that you need the Job Declarator Client (JDC), which negotiates block templates with the pool’s Job Declaration Server on your behalf. This step is optional and meaningfully more involved than the proxy alone, so treat it as a second phase once your basic setup is stable.

[job_declarator]
pool_jd_address = "jds.braiinspool.com"
pool_jd_port = 3334
authority_pubkey = "9auqWEzQDVyd2oe1JVGFLrpqYkYB9VEENSNomaD90Xa2"

[template_provider]
# Connects to your own full node for custom transaction sets
bitcoind_rpc_url = "http://127.0.0.1:8332"
bitcoind_rpc_user = "rpcuser"
bitcoind_rpc_password = "change_this_password"

[logging]
level = "info"

Note the dependency on a running Bitcoin full node for the template provider. Without one, the Job Declarator Client has no transaction set of its own to propose and effectively falls back to accepting the pool’s default template, which defeats the point of running it. Start the JDC only after confirming your node is fully synced. Custom template construction also raises a policy question worth thinking through before you deploy it: your node’s mempool policy, including any transaction filtering you apply, becomes the filter the rest of the network sees reflected in your blocks, so a deliberately restrictive node configuration carries real consequences for which transactions you help confirm.

Step 8: Containerize It With Docker Compose

Running the proxy as a bare process is fine for testing, but a container keeps the setup reproducible and makes restarts after a power blip automatic.

version: "3.9"
services:
  translator:
    image: stratummining/translator-sv2:0.8.0
    restart: unless-stopped
    ports:
      - "3333:3333"
    volumes:
      - ./tproxy-config.toml:/app/tproxy-config.toml
      - ./logs:/var/log
    command: ["-c", "/app/tproxy-config.toml"]

Bring it up with docker compose up -d and check docker compose logs -f translator for the same handshake and share-accepted lines you saw in Step 6. If you built your own image instead of pulling one, replace the image name with your local tag.

Step 9: Monitor Hashrate and Stale Shares

Migration day is when you are most likely to see a spike in stale shares, which happen when the proxy or pool issues a new job before your ASIC finishes the old one. A small bump right after switching is normal while connection latency settles. A stale rate that stays elevated for more than an hour usually points to a network issue between the proxy and the pool, not the ASIC itself.

Compare three numbers daily for the first week: ASIC-reported hashrate, proxy-reported hashrate, and pool-dashboard hashrate. They will not match exactly, since pool dashboards average over a rolling window, but they should track each other within roughly 5%. Set a calendar reminder rather than relying on memory, since a slow drift is easy to miss day to day but obvious over a week.

Keep the raw proxy log around for longer than feels necessary. A single rejected-share event tells you almost nothing on its own, but a week of logs lets you spot patterns, a rejection rate that climbs every evening, for example, might point to a neighbor’s network saturating your upstream link rather than anything wrong with the mining setup itself. Rotate logs with a simple cron job or a tool like logrotate so a long-running proxy does not slowly fill your disk.

Step 10: Harden With systemd and Firewall Rules

If you skipped Docker and are running the proxy as a native process, wrap it in a systemd unit so it survives reboots and restarts automatically on a crash.

[Unit]
Description=Stratum V2 Translator Proxy
After=network-online.target

[Service]
ExecStart=/opt/sv2-apps/target/release/translator_sv2 -c /opt/sv2-apps/tproxy-config.toml
Restart=always
RestartSec=5
User=mining

[Install]
WantedBy=multi-user.target

Save this as /etc/systemd/system/sv2-translator.service, then run systemctl enable --now sv2-translator. On the network side, only open the outbound port your pool requires, typically 3336 or similar for the SV2 endpoint, and keep the proxy’s local listener (3333 in the examples above) reachable only from your local mining VLAN, not the open internet.

Complete Working Project: Full Stack With Node and Monitoring

The individual pieces above work on their own, but a setup you actually trust long-term should run as a single reproducible stack: a synced Bitcoin full node, the Translator Proxy, the optional Job Declarator Client, and a lightweight metrics exporter so you can see trends instead of scrolling logs. The compose file below ties all four together. Adjust volume paths and the node’s RPC credentials before running it anywhere near real hashrate.

version: "3.9"
services:
  bitcoind:
    image: bitcoin/bitcoin:28.0
    restart: unless-stopped
    volumes:
      - ./bitcoin-data:/home/bitcoin/.bitcoin
    command: ["-server=1", "-rpcuser=rpcuser", "-rpcpassword=change_this_password", "-txindex=1"]

  translator:
    image: stratummining/translator-sv2:0.8.0
    restart: unless-stopped
    depends_on:
      - bitcoind
    ports:
      - "3333:3333"
    volumes:
      - ./tproxy-config.toml:/app/tproxy-config.toml
      - ./logs:/var/log
    command: ["-c", "/app/tproxy-config.toml"]

  job-declarator:
    image: stratummining/jd-client:0.8.0
    restart: unless-stopped
    depends_on:
      - bitcoind
      - translator
    volumes:
      - ./jdc-config.toml:/app/jdc-config.toml
    command: ["-c", "/app/jdc-config.toml"]

  metrics-exporter:
    image: prom/node-exporter:latest
    restart: unless-stopped
    ports:
      - "9100:9100"

Bring the whole stack up with docker compose up -d and give the node several hours to days to sync, depending on your connection and whether you start from a snapshot. The Translator Proxy and Job Declarator Client will sit idle, retrying their upstream connections, until bitcoind reports a finished initial block download. That wait is normal and not a sign anything is broken. Once the node is synced, point a monitoring tool such as Prometheus at port 9100 to graph hashrate, share acceptance, and stale-share trends over time instead of tailing log files by hand. This is the version of the setup worth running once you have validated the basic translator path from Steps 3 through 6 and decided the Job Declaration path in Step 7 is worth the added infrastructure.

What a Healthy Setup Looks Like After 24 Hours

Before troubleshooting anything, it helps to know what normal actually looks like. A day after switching, your proxy log should show a steady stream of accepted shares with occasional, isolated rejections, not a cluster of them. A typical healthy snapshot from docker compose logs --tail 20 translator reads something like this:

[2026-10-03T09:14:02Z INFO] Share accepted, difficulty=65536, worker=yourusername.worker1
[2026-10-03T09:14:19Z INFO] Share accepted, difficulty=65536, worker=yourusername.worker1
[2026-10-03T09:14:41Z WARN] Share rejected: low difficulty, worker=yourusername.worker1
[2026-10-03T09:14:55Z INFO] Share accepted, difficulty=65536, worker=yourusername.worker1
[2026-10-03T09:17:03Z INFO] New job received, job_id=889544

An occasional “low difficulty” rejection like the one above is normal variance in share timing and nothing to worry about on its own. A pool dashboard checked at the same point should show your worker online, with a reported hashrate within roughly 5% of what your ASIC’s own web interface claims, and an uptime counter that has not reset since you made the switch. If your worker shows “idle” or drops offline for more than a few minutes without a corresponding restart in your own logs, treat that as the first sign something upstream, not on your end, needs attention.

Common Pitfalls When Migrating to Stratum V2

  • Assuming the Translator Proxy gives you Job Declaration. It only provides encrypted SV2 transport between your ASIC and the pool. Transaction selection requires the separate Job Declarator Client and a synced full node.
  • Treating OCEAN as an SV2 pool. OCEAN runs its own DATUM protocol. None of the SRI tools in this tutorial will connect to it.
  • Mismatching the stratum library and sv2-apps versions. The two repositories are versioned separately. Pin both to the releases tested together, currently stratum v1.12.0 and sv2-apps v0.8.0, rather than mixing an old binary with a new config schema.
  • Copying the authority public key from an unofficial source. Always pull the pool’s SV2 authority key from its own documentation. A wrong or stale key will cause handshake failures that look identical to a network problem.
  • Running the Job Declarator Client without a synced node. Without a working Bitcoin Core RPC connection, the JDC has no transaction set to propose and silently defers to the pool’s default template.
  • Exposing the proxy’s local listener to the open internet. The downstream SV1 port has no authentication beyond the worker password. Keep it on a private network segment.
  • Forgetting that some ASIC firmware auto-reverts to a backup pool. If your ASIC has a fallback pool configured as SV1 direct-to-pool, a brief proxy restart can silently shift your hashrate to the backup pool without alerting you.
  • Starting the Job Declarator Client before the node finishes syncing. An unsynced node has no reliable view of the mempool, so any transaction set the JDC proposes during that window is built on stale data and will likely be rejected.
  • Confusing Working Group membership with deployed support. A pool joining the Stratum V2 Working Group is a signal of intent, not proof that its public endpoint accepts SV2 connections today. Check the pool’s own connection documentation, not a press release, before pointing hashrate at it.

Troubleshooting Guide

SymptomLikely CauseFix
ASIC shows “pool not responding”Proxy not running, or wrong LAN IP in ASIC configConfirm proxy process/container is up, verify IP with ip addr
Proxy logs show Noise handshake failureWrong or outdated authority public keyRe-copy the key from the pool’s current SV2 documentation
Shares accepted locally but not by poolCredentials mismatch between proxy config and pool accountDouble-check worker name format against pool’s required pattern
Stale share rate stays above 5% after an hourNetwork latency or packet loss between proxy and poolTest with mtr to the pool endpoint, consider a closer VPS region
Job Declarator fails to negotiate a templateFull node not fully synced, or RPC credentials wrongConfirm bitcoin-cli getblockchaininfo shows initialblockdownload: false
Local and pool-reported hashrate diverge by more than 10%Partial share rejection or clock drift on the proxy hostCheck timedatectl, sync NTP, review rejected-share log lines
Proxy crashes on restart, port already in useA previous process did not release the listening portlsof -i :3333 to find and kill the stale process
TLS/noise key errors after a pool-side updatePool rotated its authority key without wide noticeCheck the pool’s status page or Discord for a key-rotation announcement
ASIC silently mining on a different poolBackup pool slot configured with a direct SV1 addressRemove or update the fallback pool entry in the ASIC’s settings

Advanced Tips and Where Stratum V2 Adoption Stands

Once the basic translator path is stable, a few refinements are worth the extra effort. Running your own Job Declaration Server, rather than relying on the pool’s, is the most direct way to guarantee your proposed transaction set is actually considered, though it requires more infrastructure and a pool willing to accept externally declared jobs. Pinning the sv2-apps release in your deployment scripts rather than always pulling latest avoids a config-schema change breaking your setup unannounced, which has happened across recent SRI releases as the protocol stabilizes. If you run more than a handful of ASICs, put the Translator Proxy behind a small Prometheus exporter so hashrate and stale-share trends are graphed rather than eyeballed in logs.

Keep an eye on fee-weighted transaction selection once Job Declaration is live. A naive implementation that just grabs the highest-fee transactions from your node’s mempool can end up looking a lot like the default template any pool would have built anyway, which means the practical decentralization benefit comes less from the specific transactions you choose and more from the simple fact that the choice no longer sits exclusively with the pool. Compare your proposed block’s transaction set against a public mempool viewer like mempool.space periodically, just to sanity-check that your node’s view of the network matches reality and nothing in your configuration is silently filtering valid transactions.

It is worth setting realistic expectations about how far adoption has actually come. Public estimates vary widely: one mid-2026 analysis put native SV2 pool share at roughly 3% of network hashrate, even as pools representing about 75% of hashrate had joined the Working Group on paper. The gap between participating in standards discussions and running Job Declaration for the public is still wide.

PoolApprox. HashrateApprox. Network Share
Foundry USA~209 EH/s25.5%
AntPool~157 EH/s19.2%
F2Pool~119 EH/s14.5%
ViaBTC~87 EH/s10.6%

Figures via Spark Research‘s hashrate distribution tracking, September 2026. Moving your own ASIC to Stratum V2 will not change these top-line numbers. What it does is give you, personally, a verifiable way to confirm your hashrate is not contributing to a single operator’s unchecked control over transaction ordering, and it puts pressure on the pools you choose to mine with to finish their own SV2 rollouts.

Frequently Asked Questions

Do I need to flash new firmware on my ASIC to use Stratum V2?
No, not if you use the Translator Proxy path covered in this tutorial. The proxy translates between your ASIC’s existing Stratum V1 connection and the pool’s Stratum V2 endpoint. Native SV2 firmware is a separate, optional route for miners who want to skip the proxy entirely.

Which pools actually support Stratum V2 right now?
As of October 2026, Braiins Pool and DEMAND (DMND) are the two confirmed full-production implementations with Job Declaration enabled. ckpool added source-level support on July 31, 2026, but confirm your specific deployment before relying on it. Several large pools have joined the Stratum V2 Working Group without yet offering public native support.

Is OCEAN a Stratum V2 pool?
No. OCEAN uses a separate protocol called DATUM. It shares the broader goal of giving miners control over block templates, but it is not compatible with the SRI tools described here.

Will switching to Stratum V2 increase my mining profitability?
Not directly. Stratum V2 does not change your hashrate or the reward you earn per share. Its benefits are encrypted transport and, if you run the Job Declarator Client, control over your own transaction selection rather than a profit increase.

What happens if the Translator Proxy crashes while I’m mining?
Your ASIC will lose its connection and either sit idle or fall back to a secondary pool if one is configured. Running the proxy under systemd with Restart=always, as shown in Step 10, or in a Docker container with restart: unless-stopped, minimizes downtime from a crash.

Do I need to run a full Bitcoin node for this?
Only if you want Job Declaration and your own transaction set selection in Step 7. The basic Translator Proxy setup in Steps 3 through 6 does not require a full node.

How much does mining pool concentration actually matter for a small solo miner?
It matters less for your individual payout and more for the network’s censorship resistance. With the top four pools controlling close to 70% of hashrate as of September 2026, a small number of operators have outsized influence over which transactions get confirmed quickly. Running Stratum V2 with Job Declaration is one of the few things an individual miner can do about that, and it costs nothing beyond the time spent on this setup.

Does Stratum V2 protect me from firmware bugs like the one that hit Coldcard devices?
No, and the two are unrelated beyond both involving mining-adjacent hardware. The Coldcard incident was a seed-generation flaw in a hardware wallet’s firmware, not a mining protocol issue. Stratum V2 addresses how your ASIC talks to a pool, not how a separate device generates or stores private keys.

Can I use Bitaxe hardware with Stratum V2?
It depends on the specific board revision and firmware branch. Some community firmware builds include SV2 client support, while stock firmware generally does not. Check your exact Bitaxe model’s firmware release notes, or use the Translator Proxy path, which works regardless of what firmware your Bitaxe is running.