Compare commits
3 commits
aafe20db5b
...
f08ea2abfe
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
f08ea2abfe | ||
|
|
e48f5d454f | ||
| f6646d2715 |
10 changed files with 443 additions and 77 deletions
111
decisions/internet-finance/metadao-fund-meta-market-making.md
Normal file
111
decisions/internet-finance/metadao-fund-meta-market-making.md
Normal file
|
|
@ -0,0 +1,111 @@
|
|||
---
|
||||
type: decision
|
||||
entity_type: decision_market
|
||||
name: "MetaDAO: Fund META Market Making"
|
||||
domain: internet-finance
|
||||
status: passed
|
||||
parent_entity: "[[metadao]]"
|
||||
platform: metadao
|
||||
proposer: "Kollan House, Arad"
|
||||
proposal_url: "https://www.metadao.fi/projects/metadao/proposal/8PHuBBwqsL9EzNT1PXSs5ZEnTVDCQ6UcvUC4iCgCMynx"
|
||||
proposal_date: 2026-01-22
|
||||
resolution_date: 2026-01-25
|
||||
category: operations
|
||||
summary: "META-035 — $1M USDC + 600K newly minted META (~2.8% of supply) for market making. Engage Humidifi, Flowdesk, potentially one more. Covers 12 months. Includes CEX listing fees. 2/3 multisig (Proph3t, Kollan, Jure/Pileks). $14.6K volume, 17 trades."
|
||||
key_metrics:
|
||||
proposal_number: 35
|
||||
proposal_account: "8PHuBBwqsL9EzNT1PXSs5ZEnTVDCQ6UcvUC4iCgCMynx"
|
||||
autocrat_version: "0.6"
|
||||
usdc_budget: "$1,000,000"
|
||||
meta_minted: "600,000 META (~2.8% of supply)"
|
||||
retainer_cost: "$50,000-$80,000/month"
|
||||
volume: "$14,600"
|
||||
trades: 17
|
||||
pass_price: "$6.03"
|
||||
fail_price: "$5.90"
|
||||
tags: [metadao, market-making, liquidity, cex-listing, passed]
|
||||
tracked_by: rio
|
||||
created: 2026-03-24
|
||||
---
|
||||
|
||||
# MetaDAO: Fund META Market Making
|
||||
|
||||
## Summary & Connections
|
||||
|
||||
**META-035 — market making budget.** $1M USDC + 600K newly minted META (~2.8% of supply) for engaging market makers (Humidifi, Flowdesk, +1 TBD). Most META expected as loans (returned after 12 months). Covers retainers ($50-80K/month), USDC loans ($500K), META loans (300K), and CEX listing fees (up to 300K META). KPIs: >95% uptime, ~40% loan utilization depth at ±2%, <0.3% spread. 2/3 multisig: Proph3t, Kollan, Jure (Pileks). $14.6K volume, only 17 trades — the lowest engagement of any MetaDAO proposal.
|
||||
|
||||
**Outcome:** Passed (~Jan 2026).
|
||||
|
||||
**Connections:**
|
||||
- 17 trades / $14.6K volume is by far the lowest engagement on any MetaDAO proposal. The market barely traded this. Low engagement on operational proposals validates [[MetaDAOs futarchy implementation shows limited trading volume in uncontested decisions]] — when there's no controversy, the market provides a thin rubber stamp.
|
||||
- "Liquidity begets liquidity. Deeper books attract more participants" — the same liquidity constraint that motivated the Dutch auction ([[metadao-increase-meta-liquidity-dutch-auction]]) in 2024, now addressed through professional market makers
|
||||
- "We plan to strategically work with exchanges: we are aware that once you get one T1 exchange, the dominos start to fall more easily" — CEX listing strategy
|
||||
- "At the end of 12 months, unless contradicted via future proposal, all META would be burned and all USDC would be returned to the treasury" — the loan structure means this is temporary dilution, not permanent
|
||||
|
||||
---
|
||||
|
||||
## Full Proposal Text
|
||||
|
||||
**Type:** Operations Direct Action
|
||||
|
||||
**Author(s):** Kollan House, Arad
|
||||
|
||||
### Summary
|
||||
|
||||
We are requesting $1M and 600,000 newly minted META (~2.8% of supply) to engage market makers for the META token. Most of this is expected to be issued as loans rather than as a direct expense. This would cover at least the next 12 months.
|
||||
|
||||
At the end of 12 months, unless contradicted via future proposal, all META would be burned and all USDC would be returned to the treasury.
|
||||
|
||||
We plan to engage Humidifi, Flowdesk, and potentially one more market maker for the META/USDC pair.
|
||||
|
||||
This supply also allows for CEX listing fees, although we would negotiate those terms aggressively to ensure best utilization. How much is given to each exchange and market maker is at our discretion.
|
||||
|
||||
### Background
|
||||
|
||||
Liquidity begets liquidity. Deeper books attract more participants, and META requires additional liquidity to allow more participants to trade it. For larger investors, liquidity depth is a mandatory requirement for trading. Thin markets drive up slippage at scale.
|
||||
|
||||
Market makers can jumpstart this flywheel and is a key component of listing.
|
||||
|
||||
### Specifications
|
||||
|
||||
As stated in the overview, we reserve the right to negotiate deals as we see fit. That being said, we expect to pay $50k to $80k a month to retain market makers and give up to $500k in USDC and 300,000 META in loans to market makers. We could see spending up to 300,000 META to get listed on exchanges. KPIs for these market makers at a minimum would include:
|
||||
|
||||
- Uptime: >95%
|
||||
- Depth (±) <=2.00%: ~40% Loan utilization
|
||||
- Bid/Ask Spread: <0.3%
|
||||
- Monthly reporting
|
||||
|
||||
We plan to stick to the retainer model.
|
||||
|
||||
We also plan on strategically working with exchanges: we are aware that once you get one T1 exchange, the dominos start to fall more easily.
|
||||
|
||||
The USDC and META tokens will be transferred to a multisig `3fKDKt85rxfwT3A1BHjcxZ27yKb1vYutxoZek7H2rEVE` for the purposes outlined above. It is a 2/3 multisig with the following members:
|
||||
|
||||
- Proph3t
|
||||
- Kollan House
|
||||
- Jure (Pileks)
|
||||
|
||||
---
|
||||
|
||||
## Market Data
|
||||
|
||||
| Metric | Value |
|
||||
|--------|-------|
|
||||
| Volume | $14,600 |
|
||||
| Trades | 17 |
|
||||
| Pass Price | $6.03 |
|
||||
| Fail Price | $5.90 |
|
||||
|
||||
## Raw Data
|
||||
|
||||
- Proposal account: `8PHuBBwqsL9EzNT1PXSs5ZEnTVDCQ6UcvUC4iCgCMynx`
|
||||
- Proposal number: META-035 (onchain #1 on new DAO)
|
||||
- DAO account: `CUPoiqkK4hxyCiJcLC4yE9AtJP1MoV1vFV2vx3jqwWeS`
|
||||
- Proposer: `tSTp6B6kE9o6ZaTmHm2ZwnJBBtgd3x112tapxFhmBEQ`
|
||||
- Autocrat version: 0.6
|
||||
|
||||
## Relationship to KB
|
||||
- [[metadao]] — parent entity, liquidity infrastructure
|
||||
- [[MetaDAOs futarchy implementation shows limited trading volume in uncontested decisions]] — 17 trades is the empirical extreme
|
||||
- [[metadao-increase-meta-liquidity-dutch-auction]] — earlier liquidity solution (manual Dutch auction vs professional market makers)
|
||||
- [[futarchy adoption faces friction from token price psychology proposal complexity and liquidity requirements]] — market making addresses the liquidity friction
|
||||
159
decisions/internet-finance/metadao-omnibus-migrate-and-update.md
Normal file
159
decisions/internet-finance/metadao-omnibus-migrate-and-update.md
Normal file
|
|
@ -0,0 +1,159 @@
|
|||
---
|
||||
type: decision
|
||||
entity_type: decision_market
|
||||
name: "MetaDAO: Omnibus Proposal - Migrate and Update"
|
||||
domain: internet-finance
|
||||
status: passed
|
||||
parent_entity: "[[metadao]]"
|
||||
platform: metadao
|
||||
proposer: "Kollan, Proph3t"
|
||||
proposal_url: "https://www.metadao.fi/projects/metadao/proposal/Bzoap95gjbokTaiEqwknccktfNSvkPe4ZbAdcJF1yiEK"
|
||||
proposal_date: 2026-01-02
|
||||
resolution_date: 2026-01-05
|
||||
category: mechanism
|
||||
summary: "META-034 — The big migration. New DAO program v0.6.1 with FutarchyAMM. Transfer $11.2M USDC. Migrate 90% liquidity from Meteora to FutarchyAMM. Burn 60K META. Amend Marshall Islands DAO Operating Agreement + Master Services Agreement. New settings: 300bps pass, -300bps team, $240K/mo spending, 200K META stake."
|
||||
key_metrics:
|
||||
proposal_number: 34
|
||||
proposal_account: "Bzoap95gjbokTaiEqwknccktfNSvkPe4ZbAdcJF1yiEK"
|
||||
autocrat_version: "0.5"
|
||||
usdc_transferred: "$11,223,550.91"
|
||||
meta_burned: "60,000"
|
||||
spending_limit: "$240,000/month"
|
||||
stake_required: "200,000 META"
|
||||
pass_threshold: "300 bps"
|
||||
team_pass_threshold: "-300 bps"
|
||||
volume: "$1,100,000"
|
||||
trades: 6400
|
||||
pass_price: "$9.51"
|
||||
fail_price: "$9.16"
|
||||
tags: [metadao, migration, omnibus, futarchy-amm, legal, v0.6.1, passed]
|
||||
tracked_by: rio
|
||||
created: 2026-03-24
|
||||
---
|
||||
|
||||
# MetaDAO: Omnibus Proposal - Migrate and Update
|
||||
|
||||
## Summary & Connections
|
||||
|
||||
**META-034 — the omnibus migration that created the current MetaDAO.** Five actions in one proposal: (1) sign amended Marshall Islands DAO Operating Agreement, (2) update Master Services Agreement with Organization Technology LLC, (3) migrate $11.2M USDC + authorities to new program v0.6.1, (4) move 90% of Meteora liquidity to FutarchyAMM, (5) burn 60K META. New DAO settings: 300bps pass threshold, -300bps team threshold, $240K/mo spending limit, 200K META stake required. $1.1M volume, 6.4K trades. Passed.
|
||||
|
||||
**Outcome:** Passed (~Jan 5, 2026).
|
||||
|
||||
**Connections:**
|
||||
- This is the URL format transition point: everything before this uses `v1.metadao.fi/metadao/trade/{id}`, everything after uses `metadao.fi/projects/metadao/proposal/{id}`
|
||||
- The -300bps team pass threshold is new and significant: team-sponsored proposals pass more easily than community proposals. "While futarchy currently favors investors, these new changes relieve some of the friction currently felt" by founders. This is a calibration of the mechanism's bias.
|
||||
- $11.2M USDC in treasury at migration time — the Q4 2025 revenue ($2.51M) plus the META-033 fundraise results
|
||||
- FutarchyAMM replaces Meteora as the primary liquidity venue — protocol now controls its own AMM infrastructure
|
||||
- The legal updates (Marshall Islands DAO Operating Agreement + MSA) align MetaDAO's legal structure with the newer ownership coin structures used by launched projects
|
||||
- 60K META burned — continuing the pattern from [[metadao-burn-993-percent-meta]], the DAO burns surplus supply rather than holding it
|
||||
|
||||
---
|
||||
|
||||
## Full Proposal Text
|
||||
|
||||
**Author:** Kollan and Proph3t
|
||||
|
||||
**Category:** Operations Direct Action
|
||||
|
||||
### Summary
|
||||
|
||||
A new onchain DAO with the following settings:
|
||||
|
||||
- Pass threshold 300 bps
|
||||
- Team pass threshold -300 bps
|
||||
- Spending limit $240k/mo
|
||||
- Stake Required 200k META
|
||||
|
||||
Transfer 11,223,550.91146 USDC
|
||||
|
||||
Migrating liquidity from Meteora to FutarchyAMM
|
||||
|
||||
Amending the Marshall Islands DAO Operating Agreement
|
||||
|
||||
Modifying the existing Master Services Agreement between the Marshall Islands DAO and the Wyoming LLC
|
||||
|
||||
Burn 60k META tokens which were kept in trust for proposal creation and left over from the last fundraise.
|
||||
|
||||
The following will be executed upon passing of this proposal:
|
||||
|
||||
1. Sign the Amended Operating Agreement
|
||||
2. Sign the updated Master Services Agreement
|
||||
3. Migrate Balances and Authorities to New Program (and DAO)
|
||||
4. Provide Liquidity to New FutarchyAMM
|
||||
5. Burn 60k META tokens (left over from liquidity provisioning and the raise)
|
||||
|
||||
### Background
|
||||
|
||||
**Legal Structure**
|
||||
|
||||
When setting up the DAO LLC in early 2024, we did so with information on hand. As we have evolved, we have developed and adopted a more agile structure that better conforms with legal requirements and better supports futarchy. This is represented by the number of businesses launching using MetaDAO. MetaDAO must adopt these changes and this proposal accomplishes that.
|
||||
|
||||
Additionally, we are updating the existing Operating Agreement of the Marshall Islands DAO LLC (MetaDAO LLC) to align it with the existing operating agreements of the newest organizations created on MetaDAO.
|
||||
|
||||
We are also updating the Master Services Agreement between MetaDAO LLC and Organization Technology LLC. This updates the contracted services and agreement terms and conditions to reflect the more mature state of the DAO post revenue and to ensure arms length is maintained.
|
||||
|
||||
**Program And Settings**
|
||||
|
||||
We have updated our program to v0.6.1. This includes the FutarchyAMM and changes to proposal raising. To align MetaDAO with the existing Ownership Coins this proposal will cause the DAO to migrate to the new program and onchain account.
|
||||
|
||||
This proposal adopts the team based proposal threshold of -3%. This is completely configurable for future proposals and we believe that spearheading this new development is paramount to demonstrate to founders that, while futarchy currently favors investors, these new changes relieve some of the friction currently felt.
|
||||
|
||||
In parallel, the new DAO is configured with an increased spending limit. We will continue to operate with a small team and maintain a conservative spend, but front loaded legal cost, audits and integration fees mandate an increased flexible spend. This has been set at $240k per month, but the expected consistent expenditure is less. Unspent funds do not roll over.
|
||||
|
||||
By moving to the new program raising proposals will be less capital constrained, have better liquidity for conditional markets and bring MetaDAO into the next chapter of ownership coins.
|
||||
|
||||
**Authorities**
|
||||
|
||||
This proposal sets the update and mint authority to the new DAO within its instructions.
|
||||
|
||||
**Assets**
|
||||
|
||||
This proposal transfers the ~11M USDC to the new DAO within its instructions.
|
||||
|
||||
**Liquidity**
|
||||
|
||||
Upon passing, we'll remove 90% of liquidity from Meteora DAMM v1 and reestablish a majority of the liquidity under FutarchyAMM (under the control of the DAO).
|
||||
|
||||
**Supply**
|
||||
|
||||
We had a previous supply used to create proposals and an additional amount left over from the fundraise which was kept to ensure proposal creation. Given the new FutarchyAMM this 60k META supply is no longer needed and will be burned.
|
||||
|
||||
### Specifications
|
||||
|
||||
- Existing DAO: `Bc3pKPnSbSX8W2hTXbsFsybh1GeRtu3Qqpfu9ZLxg6Km`
|
||||
- Existing Squads: `BxgkvRwqzYFWuDbRjfTYfgTtb41NaFw1aQ3129F79eBT`
|
||||
- Meteora LP: `AUvYM8tdeY8TDJ9SMjRntDuYUuTG3S1TfqurZ9dqW4NM` (475,621.94309) ~$2.9M
|
||||
- Passing Threshold: 150 bps
|
||||
- Spending Limit: $120k
|
||||
- New DAO: `CUPoiqkK4hxyCiJcLC4yE9AtJP1MoV1vFV2vx3jqwWeS`
|
||||
- New Squads: `BfzJzFUeE54zv6Q2QdAZR4yx7UXuYRsfkeeirrRcxDvk`
|
||||
- Team Address: `6awyHMshBGVjJ3ozdSJdyyDE1CTAXUwrpNMaRGMsb4sf` (Squads Multisig)
|
||||
- New Pass Threshold: 300 bps
|
||||
- New Team Pass Threshold: -300 bps
|
||||
- New Spending Limit: $240k
|
||||
- FutarchyAMM LP: TBD but 90% of the above LP
|
||||
|
||||
---
|
||||
|
||||
## Market Data
|
||||
|
||||
| Metric | Value |
|
||||
|--------|-------|
|
||||
| Volume | $1,100,000 |
|
||||
| Trades | 6,400 |
|
||||
| Pass Price | $9.51 |
|
||||
| Fail Price | $9.16 |
|
||||
|
||||
## Raw Data
|
||||
|
||||
- Proposal account: `Bzoap95gjbokTaiEqwknccktfNSvkPe4ZbAdcJF1yiEK`
|
||||
- Proposal number: META-034 (onchain #4)
|
||||
- DAO account: `Bc3pKPnSbSX8W2hTXbsFsybh1GeRtu3Qqpfu9ZLxg6Km`
|
||||
- Proposer: `proPaC9tVZEsmgDtNhx15e7nSpoojtPD3H9h4GqSqB2`
|
||||
- Autocrat version: 0.5
|
||||
|
||||
## Relationship to KB
|
||||
- [[metadao]] — parent entity, major infrastructure migration
|
||||
- [[metadao-burn-993-percent-meta]] — continuing burn pattern (60K this time)
|
||||
- [[metadao-services-agreement-organization-technology]] — MSA updated in this proposal
|
||||
- [[MetaDAOs Autocrat program implements futarchy through conditional token markets where proposals create parallel pass and fail universes settled by time-weighted average price over a three-day window]] — mechanism upgraded to v0.6.1 with FutarchyAMM
|
||||
|
|
@ -0,0 +1,105 @@
|
|||
---
|
||||
type: decision
|
||||
entity_type: decision_market
|
||||
name: "MetaDAO: Sell up to 2M META at market price or premium?"
|
||||
domain: internet-finance
|
||||
status: passed
|
||||
parent_entity: "[[metadao]]"
|
||||
platform: metadao
|
||||
proposer: "Proph3t"
|
||||
proposal_url: "https://www.metadao.fi/projects/metadao/proposal/GfJhLniJENRzYTrYA9x75JaMc3DcEvoLKijtynx3yRSQ"
|
||||
proposal_date: 2025-10-15
|
||||
resolution_date: 2025-10-18
|
||||
category: fundraise
|
||||
summary: "META-033 — Sell up to 2M newly minted META at market or premium. Proph3t executes with 30 days, unsold burned. Floor: max(24hr TWAP, $4.80). Max proceeds $10M. Up to $400K/day ATM sales. Response to failed DBA/Variant $6M OTC."
|
||||
key_metrics:
|
||||
proposal_number: 33
|
||||
proposal_account: "GfJhLniJENRzYTrYA9x75JaMc3DcEvoLKijtynx3yRSQ"
|
||||
autocrat_version: "0.5"
|
||||
max_meta_minted: "2,000,000 META"
|
||||
max_proceeds: "$10,000,000"
|
||||
price_floor: "$4.80 (~$100M market cap)"
|
||||
atm_daily_limit: "$400,000"
|
||||
volume: "$1,100,000"
|
||||
trades: 4400
|
||||
pass_price: "$6.25"
|
||||
fail_price: "$5.92"
|
||||
tags: [metadao, fundraise, otc, market-sale, passed]
|
||||
tracked_by: rio
|
||||
created: 2026-03-24
|
||||
---
|
||||
|
||||
# MetaDAO: Sell up to 2M META at market price or premium?
|
||||
|
||||
## Summary & Connections
|
||||
|
||||
**META-033 — the fundraise that worked after the DBA/Variant deal failed.** Sell up to 2M newly minted META at market price or premium. Proph3t executes OTC sales with 30-day window. All USDC → treasury. Unsold META burned. Floor price: max(24hr TWAP, $4.80 = ~$100M mcap). Up to $400K/day in ATM (open market) sales, capped at $2M total ATM. Max total proceeds: $10M. All sales publicly broadcast within 24 hours. $1.1M volume, 4.4K trades. Passed.
|
||||
|
||||
**Outcome:** Passed (~Oct 2025).
|
||||
|
||||
**Connections:**
|
||||
- Direct response to [[metadao-vc-discount-rejection]] (META-032): "A previous proposal by DBA and Variant to OTC $6,000,000 of META failed, with the main feedback being that offering OTCs at a large discount is -EV for MetaDAO." The market rejected the discount deal and approved the at-market deal — consistent pattern.
|
||||
- "I would have ultimate discretion over any lockup and/or vesting terms" — Proph3t retained flexibility, unlike the rigid structures of earlier OTC deals. The market trusted the founder to negotiate case-by-case.
|
||||
- The $4.80 floor ($100M mcap) is a hard line: even if market crashes, no dilution below $100M. This protects existing holders against downside while allowing upside capture.
|
||||
- "All sales would be publicly broadcast within 24 hours" — transparency commitment. Every counterparty, size, and price disclosed. This is the open research model applied to capital formation.
|
||||
- This raise funded the Q4 2025 expansion that produced $2.51M in fee revenue — the capital was deployed effectively.
|
||||
|
||||
---
|
||||
|
||||
## Full Proposal Text
|
||||
|
||||
**Author:** Proph3t
|
||||
|
||||
A previous proposal by DBA and Variant to OTC $6,000,000 of META failed, with the main feedback being that offering OTCs at a large discount is -EV for MetaDAO.
|
||||
|
||||
We still need to raise money, and we've seen some demand from funds since this proposal, so I'm proposing that I (Proph3t) sell up to 2,000,000 META on behalf of MetaDAO at the market price or at a premium.
|
||||
|
||||
### Execution
|
||||
|
||||
The 2,000,000 META would be newly-minted.
|
||||
|
||||
I would have 30 days to sell this META. All USDC from sales would be deposited back into MetaDAO's treasury. Any unsold META would be burned.
|
||||
|
||||
I would source OTC counterparties for sales.
|
||||
|
||||
All sales would be publicly broadcast within 24 hours, including the counterparty, the size, and the price of the sale.
|
||||
|
||||
I would also have the option to sell up to $400,000 per day of META in ATM sales (into the open market, either with market or limit orders), up to a total of $2,000,000.
|
||||
|
||||
The maximum amount of total proceeds would be $10,000,000.
|
||||
|
||||
### Pricing
|
||||
|
||||
The minimum price of these OTCs would be the higher of:
|
||||
- the market price, calculated as a 24-hour TWAP at the time of the agreement
|
||||
- a price of $4.80, equivalent to a ~$100M market capitalization
|
||||
|
||||
That is, even if the market price dips below $100M, no OTC sales could occur below $100M. We may also execute at a price above these terms if there is sufficient demand.
|
||||
|
||||
### Lockups / vesting
|
||||
|
||||
I would have ultimate discretion over any lockup and/or vesting terms.
|
||||
|
||||
---
|
||||
|
||||
## Market Data
|
||||
|
||||
| Metric | Value |
|
||||
|--------|-------|
|
||||
| Volume | $1,100,000 |
|
||||
| Trades | 4,400 |
|
||||
| Pass Price | $6.25 |
|
||||
| Fail Price | $5.92 |
|
||||
|
||||
## Raw Data
|
||||
|
||||
- Proposal account: `GfJhLniJENRzYTrYA9x75JaMc3DcEvoLKijtynx3yRSQ`
|
||||
- Proposal number: META-033 (onchain #3)
|
||||
- DAO account: `Bc3pKPnSbSX8W2hTXbsFsybh1GeRtu3Qqpfu9ZLxg6Km`
|
||||
- Proposer: `proPaC9tVZEsmgDtNhx15e7nSpoojtPD3H9h4GqSqB2`
|
||||
- Autocrat version: 0.5
|
||||
|
||||
## Relationship to KB
|
||||
- [[metadao]] — parent entity, capital raise
|
||||
- [[metadao-vc-discount-rejection]] — the failed deal this replaces
|
||||
- [[metadao-otc-trade-theia-2]] — Theia was likely one of the OTC counterparties (they had accumulated position)
|
||||
|
|
@ -1,17 +1,18 @@
|
|||
---
|
||||
type: claim
|
||||
domain: space-development
|
||||
description: The 500-1800km SSO altitude range represents a fundamentally different and harsher radiation environment than the 325km LEO where Starcloud-1 validated GPU operations
|
||||
description: The 51,600-satellite constellation operates in sun-synchronous orbit at altitudes where radiation exposure is significantly higher than Starcloud-1's 325km validation, creating an unvalidated technical gap
|
||||
confidence: experimental
|
||||
source: SpaceNews, Blue Origin FCC filing March 19, 2026
|
||||
created: 2026-04-14
|
||||
title: Blue Origin Project Sunrise enters an unvalidated radiation environment at SSO altitude that has no demonstrated precedent for commercial GPU-class hardware
|
||||
title: Blue Origin's Project Sunrise SSO altitude (500-1800km) enters a radiation environment with no demonstrated precedent for commercial GPU-class hardware
|
||||
agent: astra
|
||||
scope: causal
|
||||
sourcer: SpaceNews
|
||||
related_claims: ["[[starcloud-1-validates-commercial-gpu-viability-at-325km-leo-but-not-higher-altitude-odc-environments]]", "[[orbital compute hardware cannot be serviced making every component either radiation-hardened redundant or disposable with failed hardware becoming debris or requiring expensive deorbit]]"]
|
||||
supports: ["orbital-compute-hardware-cannot-be-serviced-making-every-component-either-radiation-hardened-redundant-or-disposable-with-failed-hardware-becoming-debris-or-requiring-expensive-deorbit"]
|
||||
related: ["starcloud-1-validates-commercial-gpu-viability-at-325km-leo-but-not-higher-altitude-odc-environments", "orbital-data-centers-require-five-enabling-technologies-to-mature-simultaneously-and-none-currently-exist-at-required-readiness", "blue-origin-project-sunrise-signals-spacex-blue-origin-duopoly-in-orbital-compute-through-vertical-integration", "sun-synchronous-orbit-enables-continuous-solar-power-for-orbital-compute-infrastructure"]
|
||||
---
|
||||
|
||||
# Blue Origin Project Sunrise enters an unvalidated radiation environment at SSO altitude that has no demonstrated precedent for commercial GPU-class hardware
|
||||
# Blue Origin's Project Sunrise SSO altitude (500-1800km) enters a radiation environment with no demonstrated precedent for commercial GPU-class hardware
|
||||
|
||||
Blue Origin's Project Sunrise constellation targets sun-synchronous orbit at 500-1800km altitude, which places it in a significantly harsher radiation environment than Starcloud-1's 325km demonstration orbit. The source explicitly notes that 'the entire Starcloud-1 validation doesn't apply' to this altitude range. SSO orbits at these altitudes experience higher radiation exposure from trapped particles in the Van Allen belts and increased galactic cosmic ray flux compared to the very low Earth orbit where Starcloud demonstrated GPU viability. The FCC filing contains no mention of thermal management or radiation hardening approaches, suggesting these remain unsolved technical challenges. This creates a validation gap: while Starcloud proved commercial GPUs can operate at 325km, Project Sunrise proposes deploying 51,600 satellites in an environment with fundamentally different radiation characteristics, with no intermediate demonstration planned before full-scale deployment.
|
||||
Blue Origin's Project Sunrise filing specifies sun-synchronous orbit at 500-1800km altitude for 51,600 data center satellites. This is a fundamentally different radiation environment than Starcloud-1's 325km demonstration orbit. SSO at these altitudes experiences higher radiation exposure from trapped particles in the Van Allen belts and increased cosmic ray flux. The filing contains no mention of thermal management or radiation hardening approaches, suggesting these remain unsolved. Unlike Starcloud, which validated commercial GPU operation at 325km, Project Sunrise proposes scaling directly to 51,600 satellites in a harsher environment without intermediate validation. The SSO choice enables continuous solar power (supporting the compute mission) but imposes radiation costs that haven't been demonstrated at datacenter scale. This represents a technical leap rather than incremental scaling from proven systems.
|
||||
|
|
|
|||
|
|
@ -1,17 +1,18 @@
|
|||
---
|
||||
type: claim
|
||||
domain: space-development
|
||||
description: The ODC market is converging toward the same two-player structure as heavy launch because only SpaceX and Blue Origin can vertically integrate proprietary launch, communications relay networks, and compute infrastructure at megaconstellation scale
|
||||
description: Blue Origin is replicating SpaceX's vertical integration model (launch + communications + compute) but using optical ISL instead of RF and compute as the demand anchor instead of broadband
|
||||
confidence: experimental
|
||||
source: Blue Origin FCC filing March 19, 2026; GeekWire/SpaceNews reporting
|
||||
created: 2026-04-11
|
||||
title: Blue Origin's Project Sunrise filing signals an emerging SpaceX/Blue Origin duopoly in orbital compute infrastructure mirroring their launch market structure where vertical integration creates insurmountable competitive moats
|
||||
source: SpaceNews, Blue Origin FCC filing March 19, 2026
|
||||
created: 2026-04-14
|
||||
title: Blue Origin's Project Sunrise with TeraWave signals an emerging SpaceX-Blue Origin duopoly in orbital compute through parallel vertical integration strategies
|
||||
agent: astra
|
||||
scope: structural
|
||||
sourcer: GeekWire / SpaceNews
|
||||
related_claims: ["SpaceX vertical integration across launch broadband and manufacturing creates compounding cost advantages that no competitor can replicate piecemeal.md", "[[reusable-launch-convergence-creates-us-china-duopoly-in-heavy-lift]]"]
|
||||
sourcer: SpaceNews
|
||||
supports: ["starcloud-is-the-first-company-to-operate-a-datacenter-grade-gpu-in-orbit-but-faces-an-existential-dependency-on-spacex-for-launches-while-spacex-builds-a-competing-million-satellite-constellation"]
|
||||
related: ["spacex-vertical-integration-across-launch-broadband-and-manufacturing-creates-compounding-cost-advantages-that-no-competitor-can-replicate-piecemeal", "spacex-1m-odc-filing-represents-vertical-integration-at-unprecedented-scale-creating-captive-starship-demand-200x-starlink", "blue-origin-project-sunrise-signals-spacex-blue-origin-duopoly-in-orbital-compute-through-vertical-integration", "Blue Origin cislunar infrastructure strategy mirrors AWS by building comprehensive platform layers while competitors optimize individual services", "orbital-compute-filings-are-regulatory-positioning-not-technical-readiness", "SpaceX vertical integration across launch broadband and manufacturing creates compounding cost advantages that no competitor can replicate piecemeal", "blue-origin-strategic-vision-execution-gap-illustrated-by-project-sunrise-announcement-timing"]
|
||||
---
|
||||
|
||||
# Blue Origin's Project Sunrise filing signals an emerging SpaceX/Blue Origin duopoly in orbital compute infrastructure mirroring their launch market structure where vertical integration creates insurmountable competitive moats
|
||||
# Blue Origin's Project Sunrise with TeraWave signals an emerging SpaceX-Blue Origin duopoly in orbital compute through parallel vertical integration strategies
|
||||
|
||||
Blue Origin's FCC filing for 51,600 satellites in Project Sunrise represents the second vertically-integrated orbital data center play at megaconstellation scale, following SpaceX's Starcloud. The filing reveals a three-layer vertical integration strategy: (1) New Glenn launch capability being accelerated for higher cadence, (2) TeraWave communications network (5,408 satellites, 6 Tbps throughput) as the relay layer, and (3) Project Sunrise compute layer deployed on top. This mirrors SpaceX's architecture of Starship launch + Starlink comms + Starcloud compute. The 51,600 satellite scale exceeds current Starlink constellation by an order of magnitude, signaling Blue Origin is entering to own the market, not participate in it. The vertical integration creates compounding advantages: proprietary launch economics enable constellation deployment at scales competitors cannot match; captive communications infrastructure eliminates third-party relay costs; integrated design optimizes across layers. Blue Origin's request for FCC waiver from milestone rules (50% deployment in 6 years) signals execution uncertainty, but the filing establishes regulatory position. The pattern replicates heavy launch market structure where SpaceX and Blue Origin are the only players with sufficient vertical integration and capital to compete at scale. No other ODC entrant (Starcloud, Aetherflux, Loft Orbital) has announced plans above 100 satellites or controls their own launch capability. The duopoly emerges not from first-mover advantage but from structural barriers: only companies that already solved reusable heavy lift can afford megaconstellation ODC deployment.
|
||||
Blue Origin filed simultaneously for Project Sunrise (51,600 data center satellites) and TeraWave (optical inter-satellite link backbone), creating a vertically integrated stack: New Glenn for launch, TeraWave for communications, and Project Sunrise for compute. This mirrors SpaceX's architecture (Starship for launch, Starlink for communications, 1M satellite ODC filing for compute) but with key differences. Blue Origin uses optical ISL (TeraWave) instead of RF, and positions compute as the primary demand anchor rather than broadband. The filing states Project Sunrise will 'ease mounting pressure on US communities and natural resources by shifting energy- and water-intensive compute away from terrestrial data centres.' Unlike SpaceX, which has Starlink revenue funding its learning curve, Blue Origin lacks an operational demand anchor—TeraWave and Project Sunrise are both greenfield. The simultaneous filing suggests TeraWave could become an independent communications product, similar to how Starlink serves non-SpaceX customers. This creates a potential duopoly structure where only two players have the full vertical stack (launch + comms + compute) necessary for cost-competitive orbital data centers.
|
||||
|
|
|
|||
|
|
@ -1,17 +1,18 @@
|
|||
---
|
||||
type: claim
|
||||
domain: space-development
|
||||
description: Microgravity eliminates natural convection and causes compressor lubricating oil to clog systems, making terrestrial data center cooling designs non-functional in orbit
|
||||
description: Microgravity eliminates natural convection and causes compressor lubricating oil to clog systems, blocking direct adaptation of terrestrial cooling
|
||||
confidence: experimental
|
||||
source: Technical expert commentary, The Register, February 2026
|
||||
created: 2026-04-14
|
||||
title: Orbital data center thermal management requires novel refrigeration architecture because standard cooling systems depend on gravity for fluid management and convection
|
||||
title: Orbital data center refrigeration requires novel architecture because standard cooling systems depend on gravity for fluid management and convection
|
||||
agent: astra
|
||||
scope: functional
|
||||
scope: causal
|
||||
sourcer: "@theregister"
|
||||
related_claims: ["orbital-data-center-thermal-management-is-scale-dependent-engineering-not-physics-constraint.md", "space-based computing at datacenter scale is blocked by thermal physics because radiative cooling in vacuum requires surface areas that grow faster than compute density.md", "orbital data centers require five enabling technologies to mature simultaneously and none currently exist at required readiness.md"]
|
||||
challenges: ["orbital-data-center-thermal-management-is-scale-dependent-engineering-not-physics-constraint"]
|
||||
related: ["orbital-data-center-thermal-management-is-scale-dependent-engineering-not-physics-constraint", "orbital-radiators-are-binding-constraint-on-odc-power-density-not-just-cooling-solution"]
|
||||
---
|
||||
|
||||
# Orbital data center thermal management requires novel refrigeration architecture because standard cooling systems depend on gravity for fluid management and convection
|
||||
# Orbital data center refrigeration requires novel architecture because standard cooling systems depend on gravity for fluid management and convection
|
||||
|
||||
Technical experts identified a fundamental engineering constraint for orbital data centers that goes beyond radiative cooling surface area: standard refrigeration systems rely on gravity-dependent mechanisms. In microgravity, compressor lubricating oil can clog systems because fluid separation depends on gravity. Heat cannot rise via natural convection, eliminating passive cooling pathways that terrestrial data centers use. This means orbital data centers cannot simply adapt existing data center cooling designs — they require fundamentally different thermal management architectures. The constraint is not just about radiating heat to space (which is surface-area limited), but about moving heat from chips to radiators in the first place. This adds a layer of engineering complexity beyond what most orbital data center proposals acknowledge. As one expert noted, 'a lot in this proposal riding on assumptions and technology that doesn't appear to actually exist yet.' This is distinct from the radiative cooling constraint — it's an internal fluid management problem that must be solved before the external radiation problem even matters.
|
||||
Standard terrestrial refrigeration systems face fundamental physics barriers in microgravity environments. Natural convection—where heat rises via density differences—does not occur in microgravity, eliminating passive heat transfer mechanisms. Compressor-based cooling systems rely on gravity to separate lubricating oil from refrigerant; in microgravity, oil can migrate and clog the system. This is distinct from the radiator scaling problem (which is about heat rejection to space) and represents a separate engineering challenge for the refrigeration cycle itself. Technical experts quoted in the FCC filing analysis noted that 'a lot in this proposal riding on assumptions and technology that doesn't appear to actually exist yet,' with refrigeration specifically called out as an unresolved problem. This suggests orbital data centers require either novel refrigeration architectures (possibly using capillary action, magnetic separation, or entirely different cooling cycles) or must operate without active refrigeration, relying solely on passive radiative cooling.
|
||||
|
|
|
|||
|
|
@ -1,17 +1,18 @@
|
|||
---
|
||||
type: claim
|
||||
domain: space-development
|
||||
description: Amazon's FCC analysis shows 200,000 annual satellite replacements required versus 4,600 global launches in 2025, creating a physical production constraint independent of cost or technology
|
||||
confidence: experimental
|
||||
source: Amazon FCC petition, March 2026
|
||||
description: Amazon's FCC analysis shows 200,000 annual satellite replacements required versus 4,600 global launches in 2025
|
||||
confidence: likely
|
||||
source: Amazon FCC petition, February 2026
|
||||
created: 2026-04-14
|
||||
title: SpaceX's 1 million satellite orbital data center constellation faces a 44x launch cadence gap between required replacement rate and current global capacity
|
||||
title: SpaceX's 1M satellite filing faces a 44x launch cadence gap between required replacement rate and current global capacity
|
||||
agent: astra
|
||||
scope: structural
|
||||
sourcer: "@theregister"
|
||||
related_claims: ["spacex-1m-odc-filing-represents-vertical-integration-at-unprecedented-scale-creating-captive-starship-demand-200x-starlink.md", "manufacturing-rate-does-not-equal-launch-cadence-in-aerospace-operations.md", "orbital-compute-filings-are-regulatory-positioning-not-technical-readiness.md"]
|
||||
supports: ["spacex-1m-satellite-filing-is-spectrum-reservation-strategy-not-deployment-plan", "leo-orbital-shell-capacity-ceiling-240000-satellites-physics-constraint"]
|
||||
related: ["spacex-1m-satellite-filing-is-spectrum-reservation-strategy-not-deployment-plan", "leo-orbital-shell-capacity-ceiling-240000-satellites-physics-constraint", "manufacturing-rate-does-not-equal-launch-cadence-in-aerospace-operations", "spacex-1m-odc-filing-represents-vertical-integration-at-unprecedented-scale-creating-captive-starship-demand-200x-starlink"]
|
||||
---
|
||||
|
||||
# SpaceX's 1 million satellite orbital data center constellation faces a 44x launch cadence gap between required replacement rate and current global capacity
|
||||
# SpaceX's 1M satellite filing faces a 44x launch cadence gap between required replacement rate and current global capacity
|
||||
|
||||
Amazon's FCC petition provides the most rigorous quantitative challenge to SpaceX's 1 million satellite orbital data center filing. The math is straightforward: 1 million satellites with 5-year lifespans require 200,000 replacements per year to maintain the constellation. Global satellite launch output in 2025 was under 4,600 satellites. This creates a 44x gap between required and achieved capacity. This is not a cost problem or a technology readiness problem — it is a physical manufacturing and launch capacity constraint. Even if Starship achieves 1,000 flights per year with 300 satellites per flight (300,000 satellites/year), and if ALL of those launches served only this constellation, it would barely meet replacement demand. As of March 2026, Starship is not flying 1,000 times per year. The constraint is binding at the industrial production level, not the vehicle capability level. This analysis reveals that mega-constellation filings may be constrained more by manufacturing rate and launch cadence than by any single technology barrier.
|
||||
Amazon's FCC petition provides rigorous quantitative analysis of the physical constraints on SpaceX's 1 million satellite orbital data center constellation. With a 5-year satellite lifespan, the constellation requires 200,000 satellite replacements per year to maintain operational capacity. Global satellite launch output in 2025 was under 4,600 satellites across all providers and missions. This creates a 44x gap between required and achieved capacity. Even assuming Starship reaches 1,000 flights per year with 300 satellites per flight (300,000 satellites/year capacity), and if 100% of that capacity were dedicated to this single constellation, it would barely meet replacement demand—leaving zero capacity for initial deployment, other Starlink shells, or any other missions. The constraint is not cost or technology readiness, but physical manufacturing and launch infrastructure capacity that has never existed in spaceflight history.
|
||||
|
|
|
|||
|
|
@ -1,17 +1,18 @@
|
|||
---
|
||||
type: claim
|
||||
domain: space-development
|
||||
description: Blue Origin filed simultaneously for TeraWave as the communications backbone, enabling a dual-use architecture where the mesh network has standalone value beyond Project Sunrise
|
||||
confidence: experimental
|
||||
description: Blue Origin's simultaneous filing of TeraWave as the communications backbone for Project Sunrise suggests optical inter-satellite links could become a standalone service layer
|
||||
confidence: speculative
|
||||
source: SpaceNews, Blue Origin FCC filing March 19, 2026
|
||||
created: 2026-04-14
|
||||
title: TeraWave optical inter-satellite link architecture creates an independent communications product that can be monetized separately from the orbital data center constellation
|
||||
title: TeraWave optical ISL architecture creates an independent communications product that can serve customers beyond Project Sunrise
|
||||
agent: astra
|
||||
scope: structural
|
||||
sourcer: SpaceNews
|
||||
related_claims: ["[[SpaceX vertical integration across launch broadband and manufacturing creates compounding cost advantages that no competitor can replicate piecemeal]]", "[[orbital-data-centers-embedded-in-relay-networks-not-standalone-constellations]]"]
|
||||
supports: ["orbital-data-centers-embedded-in-relay-networks-not-standalone-constellations", "blue-origin-cislunar-infrastructure-strategy-mirrors-aws-by-building-comprehensive-platform-layers-while-competitors-optimize-individual-services"]
|
||||
related: ["orbital-data-centers-embedded-in-relay-networks-not-standalone-constellations", "blue-origin-project-sunrise-signals-spacex-blue-origin-duopoly-in-orbital-compute-through-vertical-integration", "orbital-compute-filings-are-regulatory-positioning-not-technical-readiness"]
|
||||
---
|
||||
|
||||
# TeraWave optical inter-satellite link architecture creates an independent communications product that can be monetized separately from the orbital data center constellation
|
||||
# TeraWave optical ISL architecture creates an independent communications product that can serve customers beyond Project Sunrise
|
||||
|
||||
Blue Origin's simultaneous filing for TeraWave optical ISL alongside Project Sunrise reveals a vertically integrated architecture where the communications layer has independent commercial value. The filing specifies 'TeraWave optical ISL mesh for high-throughput backbone' with the ability to 'route traffic through ground stations via TeraWave and other mesh networks.' This creates optionality: if orbital data centers prove economically unviable, the TeraWave constellation could still operate as a standalone high-bandwidth communications network competing with Starlink's RF-based system. The optical ISL approach offers potential advantages in bandwidth and security over RF links. This mirrors SpaceX's vertical integration strategy but inverts the sequence—SpaceX built Starlink first as a revenue generator to fund Starship and orbital compute, while Blue Origin is attempting to build compute and communications simultaneously without an established revenue anchor.
|
||||
Blue Origin filed for TeraWave optical inter-satellite links simultaneously with Project Sunrise, positioning it as 'the communications backbone for Project Sunrise satellites.' The architecture uses laser links for high-throughput mesh networking between satellites, with ground stations accessed via TeraWave and other mesh networks. The separate filing structure (TeraWave as distinct from Project Sunrise) suggests Blue Origin may be positioning optical ISL as an independent product layer, similar to how SpaceX's Starlink serves both internal (SpaceX missions) and external customers. Optical ISL provides higher bandwidth than RF links, which could make TeraWave attractive for non-ODC applications like Earth observation data relay, military communications, or inter-constellation routing. The filing states satellites will 'route traffic through ground stations via TeraWave and other mesh networks,' implying interoperability with non-Blue Origin systems. If TeraWave becomes a standalone service, it would create a new revenue stream independent of Project Sunrise's success, reducing Blue Origin's dependency on the unproven ODC market while building the infrastructure layer that ODCs require.
|
||||
|
|
|
|||
|
|
@ -1,47 +1,39 @@
|
|||
# Project Sunrise
|
||||
|
||||
**Type:** Orbital data center constellation
|
||||
**Developer:** Blue Origin
|
||||
**Status:** FCC filing stage (as of March 2026)
|
||||
**Operator:** Blue Origin
|
||||
**Status:** FCC filing submitted (March 19, 2026)
|
||||
**Scale:** Up to 51,600 satellites
|
||||
**Orbit:** Sun-synchronous orbit (SSO), 500-1,800 km altitude
|
||||
**Architecture:** TeraWave optical inter-satellite links, Ka-band ground links
|
||||
**Timeline:** First 5,000+ satellites planned by end 2027; full deployment unlikely until 2030s
|
||||
|
||||
## Overview
|
||||
|
||||
Project Sunrise is Blue Origin's proposed orbital data center constellation filed with the FCC on March 19, 2026. The constellation would operate in sun-synchronous orbit (SSO) at 500-1,800 km altitude, using TeraWave optical inter-satellite links for high-throughput backbone communications.
|
||||
Project Sunrise is Blue Origin's proposed constellation of up to 51,600 data center satellites in sun-synchronous orbit. The constellation would use TeraWave optical inter-satellite links for high-throughput backbone communications and Ka-band for telemetry, tracking, and control.
|
||||
|
||||
## Technical Specifications
|
||||
|
||||
- **Orbit:** Sun-synchronous, 500-1,800 km altitude
|
||||
- **Constellation size:** Up to 51,600 satellites
|
||||
- **Orbital planes:** 5-10 km altitude separation
|
||||
- **Orbital planes:** 5-10 km apart in altitude
|
||||
- **Satellites per plane:** 300-1,000
|
||||
- **Communications:** TeraWave optical ISL mesh, Ka-band TT&C for ground links
|
||||
- **Primary communications:** TeraWave optical ISL mesh
|
||||
- **Ground-to-space:** Ka-band TT&C
|
||||
- **Power:** Solar-powered
|
||||
|
||||
## Architecture
|
||||
|
||||
- TeraWave optical ISL mesh for high-throughput backbone
|
||||
- Traffic routing through ground stations via TeraWave and other mesh networks
|
||||
- Simultaneous filing for TeraWave as communications backbone infrastructure
|
||||
|
||||
## Stated Rationale
|
||||
|
||||
Blue Origin claims Project Sunrise will "ease mounting pressure on US communities and natural resources by shifting energy- and water-intensive compute away from terrestrial data centres, reducing demand on land, water supplies and electrical grids." The solar-powered architecture bypasses terrestrial power grid constraints.
|
||||
|
||||
## Timeline
|
||||
|
||||
- **2026-03-19** — FCC filing submitted
|
||||
- **2027** (projected) — First 5,000+ TeraWave satellites planned
|
||||
- **2030s** (industry assessment) — Realistic deployment timeframe per SpaceNews analysis
|
||||
Blue Origin's filing states: "Project Sunrise will ease mounting pressure on US communities and natural resources by shifting energy- and water-intensive compute away from terrestrial data centres, reducing demand on land, water supplies and electrical grids."
|
||||
|
||||
## Context
|
||||
|
||||
- Filed 7 weeks after SpaceX's 1M satellite filing (January 30, 2026)
|
||||
- Represents ~22% of total LEO orbital capacity (~240,000 satellites per MIT TR)
|
||||
- Unlike SpaceX's 1M filing, 51,600 is within physical LEO capacity limits
|
||||
- No demonstrated thermal management or radiation hardening approach disclosed in filing
|
||||
- SSO 500-1800km altitude represents harsher radiation environment than Starcloud-1's 325km validation orbit
|
||||
- Filed 7 weeks after SpaceX's 1M satellite ODC filing (January 30, 2026)
|
||||
- Represents ~22% of total LEO orbital capacity (~240,000 satellites)
|
||||
- Unlike SpaceX's 1M filing, Project Sunrise's 51,600 is within physical LEO capacity limits
|
||||
- SSO altitude (500-1800km) is a harsher radiation environment than Starcloud-1's 325km demonstration
|
||||
- No disclosed thermal management or radiation hardening approach in public filing
|
||||
|
||||
## Sources
|
||||
## Timeline
|
||||
|
||||
- SpaceNews, March 20, 2026: "Blue Origin joins the orbital data center race"
|
||||
- **2026-03-19** — FCC application filed for 51,600-satellite constellation
|
||||
- **2027** (planned) — First 5,000+ TeraWave satellites
|
||||
- **2030s** (projected) — Full deployment timeline per industry sources
|
||||
|
|
@ -1,33 +1,27 @@
|
|||
# TeraWave
|
||||
|
||||
**Type:** Optical inter-satellite link communications network
|
||||
**Type:** Optical inter-satellite link (ISL) communications system
|
||||
**Developer:** Blue Origin
|
||||
**Status:** FCC filing stage (as of March 2026)
|
||||
**Status:** FCC filing submitted (March 19, 2026)
|
||||
**Primary application:** Project Sunrise orbital data center backbone
|
||||
**Architecture:** Laser-based mesh networking
|
||||
|
||||
## Overview
|
||||
|
||||
TeraWave is Blue Origin's optical inter-satellite link (ISL) communications system, filed simultaneously with Project Sunrise on March 19, 2026. While designed as the communications backbone for Project Sunrise's orbital data center constellation, the architecture enables standalone operation as an independent high-bandwidth communications network.
|
||||
TeraWave is Blue Origin's optical inter-satellite link system, filed simultaneously with Project Sunrise as the communications backbone for the orbital data center constellation. The system uses laser links for high-throughput mesh networking between satellites.
|
||||
|
||||
## Technical Approach
|
||||
## Architecture
|
||||
|
||||
- **Technology:** Optical (laser) inter-satellite links
|
||||
- **Architecture:** Mesh network topology
|
||||
- **Ground links:** Ka-band TT&C
|
||||
- **Routing:** Traffic routing through ground stations via TeraWave and other mesh networks
|
||||
- **Interoperability:** Designed to interface with external mesh networks
|
||||
- **Link type:** Optical (laser)
|
||||
- **Topology:** Mesh network
|
||||
- **Ground access:** Via TeraWave and other mesh networks
|
||||
- **Bandwidth:** High-throughput (specific capacity not disclosed)
|
||||
|
||||
## Strategic Positioning
|
||||
|
||||
TeraWave represents a dual-use architecture where the communications layer has independent commercial value beyond the orbital data center payload. This creates optionality: if orbital data centers prove economically unviable, TeraWave could operate as a standalone high-bandwidth communications network competing with RF-based systems like Starlink.
|
||||
|
||||
The optical ISL approach offers potential advantages in bandwidth and security over RF links, though at higher complexity and pointing requirements.
|
||||
The separate filing structure (TeraWave distinct from Project Sunrise) suggests Blue Origin may be positioning optical ISL as an independent service layer that could serve customers beyond Project Sunrise, similar to how SpaceX's Starlink serves both internal and external customers.
|
||||
|
||||
## Timeline
|
||||
|
||||
- **2026-03-19** — FCC filing submitted alongside Project Sunrise
|
||||
- **2027** (projected) — First 5,000+ TeraWave satellites planned
|
||||
|
||||
## Sources
|
||||
|
||||
- SpaceNews, March 20, 2026: "Blue Origin joins the orbital data center race"
|
||||
- **2026-03-19** — FCC application filed simultaneously with Project Sunrise
|
||||
- **2027** (planned) — First 5,000+ TeraWave satellites as part of Project Sunrise deployment
|
||||
Loading…
Reference in a new issue