A DGX Station in cooperative hands does one thing the spec cannot: it makes the four primitives measurable in the world. Until there is hardware running, "verified service delivery" is a description of a future obligation. The moment compute, transfer, and memory are flowing through infrastructure the LCA owns, the attestation layer has something to attest to, and the stamp moves from credit-in-principle to credit-in-redemption.
Three concrete enablements follow from that shift. First, sovereign inference: members' conversations and computations stay within infrastructure governed by the people using it, which is the substantive content of the "post office of AI" framing rather than its rhetoric. Second, closed-loop cost discovery: capital expenditure becomes a fixed quantity of annual capacity, and rates can be set against actual operating cost rather than against the psychology of market comparison. Third, federation becomes demonstrable rather than promised: a second node anywhere proves the protocol works between cooperatives, which is what makes the architecture a network rather than a single installation.
The DGX Station is 748–784GB of unified coherent memory at ~$85–100K, depending on OEM. Kimi K2.7-Code at INT4 needs ~577GB peak VRAM including activations and KV cache (Spheron); it fits, but with limited headroom for context and concurrency. The 325GB figure in Aaron's note appears to be weights-only or a smaller variant. The fit is real; the margins are thin. K2.6 at Unsloth's Dynamic 2-bit lands at ~350GB and gives more breathing room (Unsloth).
The Digital Post taxonomy translates onto the GB300 hardware cleanly, but each primitive carries its own measurement and accounting question. The cards below are the conceptual map; the rate work in the next section grounds each in observable units.
One observation worth surfacing before the math: the postal taxonomy was built around moving messages. AI-era infrastructure adds a fifth implicit primitive: model quality / lineage. The same GPU-hour delivered through Kimi K2.7 versus a smaller, faster model is not the same product, even though the resource accounting reads identically. The cooperative will need a posture on this — either treat model selection as a member choice with its own rate card, or bundle "house model" service and account for model substitution in the quarterly rate-setting. Worth naming so it doesn't sneak in as a hidden default.
Aaron's question — how to benchmark the rate — has three honest answers, each with a different commitment underneath it. A well-governed cooperative uses all three and lets them constrain each other.
Total annual operating cost divided by total annual delivered capacity at assumed utilization. This is the rate below which the cooperative cannot sustainably operate, and it is what gets published in the Operating Agreement as the rate-setting basis.
| Line item | Annual | Note |
|---|---|---|
| Hardware amortization | $25,000 | $100K capex / 4-yr useful life |
| Energy (PUE-adjusted) | $3,500 | ~2kW continuous × 1.5 PUE × $0.10/kWh |
| Upstream bandwidth | $8,000 | Commercial fiber, modest tier |
| Space, insurance, maintenance | $8,000 | Boulder commercial rates |
| Sysadmin and member support | $40,000 | Part-time; could be in-kind initially |
| Guarantee Fund contribution | $6,000 | ~7% of revenue, smoothed |
| Steward fee (Purpose Trust) | $400 | 0.5% of gross revenue |
| Operating cost | $90,900 | Annual, midpoint estimate |
At ~60% utilization delivering ~1B output tokens/year (Kimi K2.7 INT4, conservative throughput), this is ~$0.09/M output tokens. At 20% utilization the floor rises to ~$0.27/M. Utilization is the dominant variable; the rate card is more about projected demand than hardware cost.
The Kimi K2.7 API runs at $0.95/M input and $4/M output through Moonshot (Flowtivity). Claude Opus and GPT-5.2 sit higher. The market ceiling tells the cooperative what members would otherwise pay; it disciplines the cost-recovery floor by forcing the question: if our delivered cost climbs above market, what are we offering that justifies it?
For a cooperative, the right answer is usually data sovereignty, governance accountability, and patronage dividend — not raw price competition. But the comparison should be made and published, not avoided. Members should be able to see what they would pay outside the cooperative and what they pay inside it, with the difference labeled honestly as the cost of self-governance.
Some uses — civic applications, public works visibility, services for low-resource members — may need a rate below cost recovery. The cooperative can fund this through explicit cross-subsidy: heavier or commercial users carry a margin that subsidizes civic and access-equity use. This is the patronage tradition; it works only if it is visible in the rate card rather than buried in averaging.
The Operating Agreement can name this directly: a tiered rate card with civic, member, and commercial tiers, with the subsidy ratio voted on at the annual meeting. This preserves member agency over the moral economics of the cooperative.
Allocation is distinct from rate setting: it answers how the resource flows, not what it costs. Four patterns are available, and most cooperatives end up running two or three of them in combination.
Per-unit metering tracks every GPU-second, byte transferred, and memory-hour held. It is the most accurate and the most legible to accounting, and it is what runs underneath everything else. Bundled access — "a stamp redeems for one inference session of typical scope" — gives members predictability and keeps the user-facing surface simple, the way a Forever Stamp does for postal mail regardless of envelope weight within reason. Tiered membership includes a baseline stamp allotment with each membership class and meters overage against it, similar to a transit pass with surge fares. Priority class reserves a slice of capacity for civic applications and member-facing services that the cooperative has chosen to privilege, with the remainder queued.
The recommendation, given the postal frame the cooperative has chosen, is to run metering underneath as the source of truth and surface bundled stamps to members. The accounting is precise; the experience is simple. Civic priority can be a governance setting (what percentage of capacity is reserved for civic class), voted at the annual meeting and published quarterly.
The Resources–Events–Agents pattern fits the cooperative's stated architecture without modification. Resources are the four primitives plus the stamp itself as value carrier. Agents are members, the Operator LCA, node operators (which may federate beyond Boulder), the Purpose Trust, and the Guarantee Fund. Events happen at three cadences:
Service request → resource consumed → attestation event logged → stamp balance decremented from the member's account, credited to the node's delivered-service ledger. This is the per-transaction primitive that all higher cycles depend on.
Actual delivered units and actual operating costs reconciled against the prior quarter's published rates. Variance reviewed by the cooperative's finance steward. New rates proposed for member ratification, published in advance per the Operating Agreement. This is where the Forever Stamp mechanic actually lives: stamps don't expire, but what they redeem for adjusts to reality.
Net margin allocated to patronage refund proportional to member usage. Guarantee Fund topped up to maintain minimum reserve ratio against future service-delivery obligations. Steward fee (0.5% gross revenue) distributed to the Purpose Trust. Operating Agreement compliance reviewed; rate-setting methodology re-examined; tier ratios and civic reservation re-voted.
Hardware ages out in roughly four years. The Forever Stamp promise asks the cooperative to honor redemption indefinitely. Either the rate card includes ongoing refresh capex (raising the floor), or the cooperative explicitly time-bounds the stamp ("valid through the operating life of issued hardware, with continuity through federation"). Neither is wrong; the choice should be deliberate, not deferred.
At 60% utilization the rate card holds. At 20% it doesn't. The single most important governance question may not be rate setting but demand-building — what services run on the node that produce sustained, predictable utilization. The civic applications named in the architecture (programmable policy, outcomes-based contracts, verifiable credentials) are also the demand strategy.
Model quality, model lineage, and inference characteristics (latency, context length, agent orchestration) carry weight that the four primitives don't directly capture. The cooperative may need either a fifth primitive (model-service) or a clear posture that model choice is a member-side concern with separate accounting.
One DGX Station is one box that can fail. The Guarantee Fund is the member-protection answer in policy, but federation with a second node is the structural answer. The question is whether the first node should operate long enough to demonstrate the model, or whether a second node should be stood up in parallel even at lower spec.