Foundry USA Pool Stratum Config: Setup for US Miners

Foundry USA is structurally different from most public Bitcoin pools. It runs an FPPS payout model and exposes a stratum interface like any other pool, but onboarding requires KYC and the pool’s product positioning skews enterprise — large self-mining operators, public miners, and hosting providers rather than walk-up retail accounts. That has implications for any operator approaching a foundry usa pool stratum config: the account-creation phase is a paperwork exercise before it becomes a copy-paste exercise. This guide walks through what to expect on both sides — Foundry-side onboarding particulars and Antminer-side configuration once the account is approved.

What a Foundry USA stratum config involves end-to-end

Mechanically, configuring an Antminer or any other modern ASIC to point at Foundry USA is identical to any other pool: open the Miner Configuration tab, paste a stratum URL into one of the three pool slots, set a worker name in account.worker format, save, and verify. Foundry publishes the active stratum endpoints in its onboarding documentation provided to approved customers. Public-facing pool URLs and TCP ports should be sourced from Foundry’s official documentation at the time of deployment rather than from third-party forum posts that may be outdated.

What is different is the precondition. A retail operator cannot self-serve sign up at Foundry the way they can at F2Pool or AntPool. Foundry’s account model historically requires US-entity onboarding with KYC documentation, a contractual relationship, and in practice a hashrate floor that aligns with the pool’s enterprise focus. Operators should treat this as a sales-cycle engagement rather than a five-minute web signup.

Step 1 — qualify and onboard with Foundry

Begin by contacting Foundry through the channels published on its official site. The onboarding process typically requires entity formation documents (LLC, corporation, or trust), beneficial-owner KYC, banking information for fiat settlement if applicable, and a description of the intended hashrate. Foundry’s customer support handles the workflow; expect the process to take days to weeks rather than minutes.

The KYC requirement reflects Foundry’s regulatory posture as a US-domiciled mining-services business operating under DCG. That posture cuts both ways — it filters out anonymous retail miners, which some operators see as a benefit (counterparty stability, no pool operator with unclear legal exposure) and others see as a cost (no privacy-preserving option, no fast onboarding). Operators weighing the trade-off should also read the Foundry USA pool review for context on the pool’s history, fee model, and customer base.

Step 2 — receive account credentials and endpoints

Once onboarded, Foundry issues account credentials and the stratum endpoint details. The account model is typically a parent account with worker-level subdivision: the segment before the dot in the worker name maps to the customer account, the segment after the dot is a free-text worker identifier the operator controls. Some customer arrangements include sub-account features comparable to AntPool’s, which lets a single parent account segment hashrate and payouts across rigs, locations, or end-customers.

The endpoints provided are typically clustered around US regions because the customer base is US-concentrated. Foundry has historically operated stratum infrastructure with low-latency peering into major US data-center markets, which works in favour of customers operating in those geographies. Operators outside the US can still connect, but the latency picture will vary by geography; the principles in the stale-share explainer apply the same way they do at any other pool.

Step 3 — configure the Antminer’s three pool slots

Open the Antminer’s web UI, navigate to Miner Configuration, and populate the slots:

• Pool 1: Primary Foundry stratum URL, account.workerid worker name, password per Foundry’s documentation.
• Pool 2: Backup Foundry endpoint if Foundry publishes multiple regional or redundant hosts to the customer.
• Pool 3: Tertiary slot. Some Foundry customers use this for a non-Foundry fallback as belt-and-suspenders; others leave it empty if Foundry-provided redundancy is considered sufficient.

The worker name is the operational telemetry hook. At an enterprise farm, the convention typically encodes building, room, rack, and rack-unit so a “worker offline” alert from Foundry’s dashboard or webhook maps directly to a physical maintenance ticket. Operators new to enterprise-grade ASIC operations should review how an ASIC actually submits shares to understand what the worker label is decorating.

Step 4 — understand Foundry’s FPPS payout

Foundry operates an FPPS payout model on Bitcoin. The pool credits the miner for the expected block subsidy plus a rolling-average share of transaction fees on every accepted share, regardless of whether the pool finds a block on a given day. Foundry’s published pool fee for Bitcoin sits in the low-single-digit range; the current rate is documented in Foundry’s customer materials and operators should consult those directly.

FPPS suits Foundry’s enterprise customer base for the same reason it suits any cash-flow-sensitive operator: predictable daily settlement removes the variance that PPLNS pools transfer to miners. Public-miner customers reporting hashrate to investors particularly benefit from the smoothness because it lines up with the monthly hashrate-and-revenue disclosures common in SEC filings from listed mining companies.

Step 5 — apply, reboot, verify, and reconcile

Save the configuration, optionally power-cycle the rig to clear state, and watch the local Antminer log accumulate accepted shares. Within five to fifteen minutes the Foundry dashboard should reflect a live hashrate reading per worker. Reject rates above 1% warrant investigation — typically a latency or firmware issue rather than a pool issue.

Reconciliation is where Foundry’s enterprise framing shows up most concretely. Public-miner customers tie pool-side accepted-hashrate readings to their own SCADA-style fleet monitoring, then tie payouts to the accounting ledger that will eventually flow into investor disclosures. The audit trail Foundry provides is calibrated for that workflow — exportable share and payout history rather than just a real-time dashboard.

How Foundry fits into the US mining landscape

Foundry has historically commanded a large share of network hashrate in part because its customer base includes several of the largest publicly-traded Bitcoin miners. Hashrate Index’s pool distribution dashboard tracks the share over time and is a useful sanity check on any pool’s standing within the broader network.

The KYC-gated onboarding model means Foundry is rarely the first pool a new retail miner connects to. Operators ramping a single Antminer at home will more typically start with AntPool, F2Pool, or Braiins. Operators ramping a 500-unit farm under a US LLC may find Foundry’s onboarding overhead a small price for predictable counterparty risk. The Bitcoin mining hub on Coin Web Mining consolidates the broader BTC-mining context including the supporting infrastructure and economics that determine which path makes sense.

Common deployment errors and how to handle them

The first frequent error is using a worker label that collides with another rig under the same parent account. As at any pool, two workers sharing the same identifier merge in dashboards and break per-unit diagnostics. Unique labels per physical unit are mandatory at any operational scale.

The second is treating Foundry’s onboarding as a hurdle rather than a feature. The KYC and contractual overhead exists because Foundry is a US-regulated mining-services entity — that posture is what makes some institutional customers prefer it over offshore alternatives. Operators choosing Foundry should be choosing the legal posture as much as the technical service.

The third is forgetting to plan for non-Foundry redundancy. Even an enterprise pool can have an incident; a tertiary slot pointing at a different pool entirely is cheap insurance for any operator whose revenue depends on continuous hashrate uptime. Patterns for this are covered in the dedicated failover-configuration guide.

Reading Foundry’s dashboard and export tooling

Foundry’s reporting surface is built for customers who reconcile pool data against an internal ledger rather than glance at a phone widget. The live dashboard shows per-worker hashrate with the usual real-time and rolling-window readings, and the rolling 24-hour average is the figure that should track the rig’s nameplate. The accepted-versus-rejected ratio is the same health signal as at any pool — under 1% rejected is healthy, a climb past 2% points to a latency or firmware problem rather than anything pool-side.

Where Foundry’s enterprise framing shows up is the export layer. Rather than relying on the dashboard’s instantaneous view, customers pull exportable share and payout history and reconcile it against their own fleet-monitoring telemetry. A public miner ties accepted-hashrate readings to the monthly hashrate-and-revenue figures that flow into investor disclosures, so the audit trail matters more than the real-time graph. Operators should confirm during onboarding which export formats and API endpoints Foundry provides, because that determines how cleanly the pool data slots into existing accounting systems.

Worker-naming for an enterprise farm

At a single-rig home setup, a worker label can be almost anything. At a Foundry-scale farm of hundreds or thousands of units, the worker name is the primary key that links a pool-side alert to a physical maintenance action. The convention that holds up at scale encodes building, room, rack, and rack-unit — so a “worker offline” event maps directly to a coordinate a technician can walk to. A label that encodes nothing forces the operator to maintain a separate spreadsheet mapping arbitrary worker IDs to physical locations, which drifts out of sync the moment a rig is moved.

Some operators extend the convention to encode the firmware version or PSU model, which makes fleet-wide rollouts and thermal diagnostics auditable directly from the pool dashboard. Whatever scheme is chosen, the non-negotiable rule is uniqueness per physical unit. Two rigs sharing one worker label merge in Foundry’s dashboard, and one unit’s failure can be masked by the other’s hashrate — a particularly expensive error when the hashrate underpins an investor disclosure.

Security posture for a regulated mining operation

Foundry’s customers tend to already operate under a security and compliance regime, but the basics still apply at the rig level. The stratum connection to Foundry is outbound, so no inbound port needs exposing for mining to function. Miner management interfaces belong on an isolated management network that is not routable from the public internet, with remote access gated behind a VPN and role-based access controls. For an operation whose hashrate feeds regulated disclosures, an attacker silently repointing a block of rigs to a different pool account is both a revenue loss and a reporting-integrity problem.

The same isolation that protects the rigs also simplifies the audit story. A documented network architecture with segmented management VLANs, rotated credentials, and logged remote access is the kind of control an institutional customer’s auditors expect to see, and it costs nothing in mining performance because the outbound stratum session to Foundry is unaffected by how tightly the management plane is locked down.

References

• Foundry official site and customer documentation — Foundry
• Bitmain Antminer firmware and configuration docs — Bitmain
• Hashrate Index pool share and hashprice analytics — Hashrate Index
• SEC EDGAR public-miner filings — SEC