Products and Services

Do you plan to offer bandwidth tiers? Will there be a data cap?

All FemtoStar services are delivered on a best-effort basis, at the highest speed technically feasible with the user's hardware and with network traffic at that time. We do not impose artificial restrictions on bandwidth. The flipside of this is that, while we do not limit you to a maximum speed, we cannot guarantee you will always get one particular speed either - getting the maximum possible at all times means that, unlike a service where you are constantly limited to a certain bandwidth even when more is possible, FemtoStar performance will vary. Performance at some times being lower than at some others should be expected.

FemtoStar service is paid for in terms of the amount of beam time a session consumes - that is, how long the satellite needs to spend using one of its beams to transmit data for that session. This is not the same as the amount of time a user stays connected to the network - because the beam must also serve other users and any particular user's terminal is unlikely to be consuming the full throughput of its link at all times, a connected terminal consumes much less beam time than the amount of time it remains connected, especially when usage is light. What all of this means is that there is no data cap - we don't care about how many bytes you send through the satellite, only how long the satellite must spend handling your traffic.

This means that users with larger, higher-speed terminals (see the above point) able to transfer the same amount of data in a shorter period of time will pay less for the same amount of data transferred, as they will consume less beam time in doing so. Because beam time is the network's most important resource, and is the limiting factor in terms of network performance, we believe that charging for service in terms of the actual resource - beam time - being consumed is the most fair model for service pricing.

Who makes FemtoStar terminals?
The FemtoStar Project intends to take a hybrid approach to terminal manufacturing and sales. Higher-volume "core" user terminals will be manufactured and sold primarily by hardware partners, allowing us to leverage existing manufacturing and sales infrastructure. Meanwhile, development and reference hardware, as well as more specialized terminals will be made in Canada by FemtoStar Inc., at the same facility where build our satellites. Every FemtoStar terminal is based on FemtoStar Project-developed reference designs.
What speeds do you anticipate being available?

FemtoStar is a midband Mobile Satellite Service network, designed for speeds in line with other midband Mobile Satellite Service offerings. Here, the term "midband" refers to the level of bandwidth between narrowband services, designed to provide a low-speed connection to small, usually IoT/embedded terminals, and broadband services, designed to provide a high-speed connection to large, expensive, fixed terminals.

While this middle category of service may be unfamiliar to those more used to terrestrial services, it's common in the in Mobile Satellite Service landscape, and is what's offered by services such as Inmarsat BGAN, Iridium Certus, or Thuraya IP. In these services, as in FemtoStar, designing for this middle category means that users can expect performance much better than a narrowband system, while still having a truly-portable terminal much smaller than those needed for broadband systems. Like the aforementioned MSS options, a typical FemtoStar terminal should provide in the mid-hundreds of kbps, using a terminal roughly the size of a tablet or small laptop.

Of course, FemtoStar's design still allows for flexibility on the size and speed of terminals - users should be able to choose their own balance between speed, cost, and portability. As such, depending on the size of the terminal, the FemtoStar network should be able to accomodate larger terminals in the megabits-per-second range, or smaller terminals with reduced (if still better than typical narrowband offerings) speeds in a pocket-sized form factor.

Is the FemtoStar Credit Token a cryptocurrency?

No, at least not by any usual definition of the term. While the Credit Token system is a digital system used to pay for service, and while they do make use of cryptographic signatures for security, FemtoStar Credit Tokens are not transacted on a blockchain, cannot be mined, and are not intended for use as anything other than payment for FemtoStar service.

How do I buy FemtoStar tokens? Are they available yet?

Once our network is operational, you will be able to purchase FemtoStar tokens from FemtoStar Inc. via a retail token sales portal, from a third-party reseller, or in bulk via a wholesale agreement. While FemtoStar Inc. would be capable of pre-issuing tokens that would be usable once the network was operational, they are not yet available for sale, due to the inherent risk to consumers of purchasing a service before it is available. If you are interested in working with FemtoStar Inc. as a token reseller or for a large deployment of FemtoStar hardware as an enterprise user, please contact This address has been hidden to prevent spam being received. If you are reading this website as plain text or through a screen reader, the correct address is the word inc, that's I. N. C., then the symbol spelled with the letter before B and then the letter after S, then the name of this website or of our satellite, then dot com. iLoremnipsumdolorcsit аamett fconsectetureadipiscingmelittSedodolorssemtlaciniaaacr deuismodоvitaet chendreritositm.

Who is the FemtoStar Project? Who is FemtoStar Inc.?

The FemtoStar Project is a global volunteer community of developers, working on technology for global, open communications infrastructure. For more information about the FemtoStar Project, or to contact us, see about & contact.

FemtoStar Inc., located in Canada, is the company tasked with the manufacturing and operation of the FemtoStar satellite constellation, based on the free and open-source designs and specifications developed and published by the FemtoStar Project.

FemtoStar Inc. exists to provide the FemtoStar Project with an entity which can manufacture the satellites, hold licenses for the constellation, purchase services such as satellite launch or component fabrication, and can handle the day-to-day operation of the constellation once operational. While FemtoStar Inc. consists entirely of FemtoStar Project members, and exists to manufacture and operate the system developed by the FemtoStar Project, the FemtoStar Project is entirely independent of FemtoStar Inc., and its developments are freely usable, even outside the context of the network operated by FemtoStar Inc.

Network Architecture and Other Projects

What about Starlink?

Starlink is a low-earth-orbit communications constellation developed by SpaceX. While we have a tremendous amount of respect for the engineering accomplishments of the Starlink network, its goals and those of FemtoStar are largely separate. While both intend to provide satellite communications service using low-earth orbit constellations, Starlink is designed primarily to provide consumer broadband services to large, fixed terminals (in the satellite industry, this is known as Fixed Satellite Service). FemtoStar, on the other hand, is designed for truly-mobile midband services to small and medium, portable or in-motion terminals (also known as Mobile Satellite Service).

While the Starlink network is large, its architecture is traditional - it is designed to connect users to official ground stations providing official services. While there has been talk of limited use of Starlink for point-to-point connectivity, such as for high-speed securities trading, SpaceX holds complete control over use of this feature, and it is not a part of their consumer-facing services, nor is it known to be possible with their consumer hardware. FemtoStar's open-infrastructure architecture ensures an inherently net-neutral network, wherein all hardware is usable as a ground station, and even our own services are simply one of many a satellite is able to connect users to.

Starlink terminals are uniquely identified on the network, and can be readily geolocated by the network, as they are often disallowed from accessing the network outside of the small region, or "cell", where their user's address is registered. Starlink users are required to provide a significant amount of personal information in order to purchase service, in line with traditional telecommunications services. Payments for service are handled on ground infrastructure, based on user accounts, and generally are not possible using privacy-respecting payment methods. FemtoStar users do not require any user account whatsoever, and payments are handled on the satellite itself using FemtoStar Credit Tokens. Geolocation of FemtoStar users by the FemtoStar network is, by design, infeasible.

What about Blockstream or Othernet?

Blockstream is a cryptocurrency company which offers a service named Blockstream Satellite. Othernet is a company which broadcasts data, primarily news and other text content, via satellite.

Blockstream Satellite broadcasts the Bitcoin blockchain, one-way, over six geostationary broadcasting satellites, and offers an API to transmit your own short pieces of data over the network, with payment in Bitcoin. While Blockstream does allow for remote access to the Bitcoin blockchain, it is a one-way system - it cannot be used for two-way communications, or even to send (as opposed to simply observe) cryptocurrency transactions, unless you already have an internet connection and can connect to its API.

Othernet provides one-way, broadcast data service via two geostationary satellites. This data typically consists of news, Wikipedia articles, and other low-data-rate content which can be delivered one-way.

Both of these companies purchase time on existing geostationary broadcasting satellites, of the type typically used for consumer satellite television. These services do not support, nor is the hardware provided for them capable of, any form of uplink from the user terminal. While both services are useful as tools for broadcast data distribution, they are one-way, Broadcasting Satellite Service systems, distinct from two-way communications systems in the Fixed Satellite Service (such as Starlink) and Mobile Satellite Service (such as FemtoStar).

Are you sure satellites are the right way to do this? Surely a terrestrial network would be easier?

We're big fans of a number of the terrestrial privacy-respecting communications projects currently in development - in fact, what is now FemtoStar began in concept as a terrestrial system, which we then called Private Mobile Data Protocol (PMDP).

The fundamental issue of terrestrial networks is the amount of hardware necessary to provide adequate coverage. It has taken decades of development, thousands of licenses to thousands of companies in hundreds of countries, hundreds of billions of dollars at least, and more than 7 million cell towers to build mainstream cellular networks out to their current coverage, and even with this it's likely you still sometimes have problems getting cellular service. We began with the assumption that a terrestrial network would be the only practical solution, and extensively tested a variety of popular license-free radio hardware - including LoRa, 802.11, and 802.15.4 transceivers - in real-world urban and suburban environments. Eventually, we were forced to admit that a workable community-operated mobile telecommunications network would be impractical in all but the most densely-populated areas, and even there only with the right combination of ideally-situated transceivers and minimal obstruction by structures.

As a thought experiment in community-run terrestrial networks, next time you leave home, ask yourself if you are ever more than 1 kilometer (3200 feet) away from somewhere a mesh node or base station in a community-run terrestrial network could be installed without being removed, stolen, or tampered with, and if anyone nearby would be willing to purchase, install, and maintain such a device. We installed a series of LoRa transceivers in a real city in 2019 as a test of our PMDP concept, mapped their coverage under a variety of conditions, and came to the conclusion that that, rather than being an easier solution, such a network was likely outright impossible in most circumstances.

Where such networks can exist, they genuinely do have some advantages over satellite-based networks - however, in most places, it is simply not realistic to build them. We found this out the hard way. It's also worth noting that FemtoStar can coexist with these networks symbiotically - where these networks can be built, given that this is likely to occur in clusters of nodes or base stations (such as in a city center) separated by a substantial distance, we believe FemtoStar could be extremely useful to link these sections together into larger, more resillient networks.

What about mesh networks?

See the above point. While mesh networks are able to partially solve the problem of base station range by allowing every user device to extend coverage, this still does not allow for coverage where there are no nodes. The same thought experiment applies - are you always within a kilometer of someone else who might have a node in the mesh? If you have your own node in the mesh, is there often another node nearby for it to mesh with? If not, a mesh network may not be practical in your situation. Even where mesh networks are practical, FemtoStar could still be used to interconnect regions where the mesh is available, even when they are separated by large regions with no nodes.

I've used satellite internet, and the latency is pretty bad - is this true of FemtoStar too?

If the service you have used was via a geostationary network, then not to nearly the same degree. While the distance to the satellite does add some amount of latency due to the time taken for the signal to reach the satellite, the round-trip propagation time to a low-earth orbit satellite is a handful of milliseconds, not the hundreds of milliseconds familiar to users of geostationary satellite networks.

In general, latency via low-earth orbit satellite networks, including FemtoStar, is comparable to that of terrestrial mobile networks, and is generally unproblematic for most applications.

How do you plan to mitigate orbital debris?

In contrast to the vast majority of small satellites, FemtoStar plans to include electric propulsion onboard the satellites used in our constellation, allowing them to be repositioned as needed and cleanly deorbited at end-of-life. The FemtoStar Project is working closely with Applied Ion Systems, a leading developer of open-hardware smallsat propulsion hardware, to develop a specialized implementation of their technology for use onboard our satellite.

In addition to this, while the exact orbital parameters of the final constellation are undecided at this time, the requirement to launch via typical rideshare missions generally entails deployment at orbits typically considered sufficiently self-cleaning to accomodate satellites without any onboard propulsion at all, causing them to eventually re-enter simply due to atmospheric drag. While satellites used in the constellation are likely to raise their orbits somewhat after deployment, any satellites not raising their orbit into the final constellation (such a satellite that experienced a propulsion failure during launch, or an early test satellite without propulsion) would simply remain at their deployed altitude and, at end-of-life, re-enter due to atmospheric drag like a typical smallsat.

Is this a megaconstellation? How many satellites do you need?

The network can theoretically work with as little as a single satellite, however of course this configuration does not allow for a stationary user to receive continuous coverage. Practical constellation layouts begin at around 48 satellites (and include the layout shown on our homepage). We have considered the possibility of a larger constellation of up to 96 satellites, however we believe that the most reasonable approach would be to begin with the minimum practical number of satellites (likely 48) and then scale up the constellation with new satellites as needed.

What if a satellite fails? Will the network become unreliable?

The FemtoStar network is designed to provide multiple levels of protection against failure of spacecraft, and against failure of the network due to the failure of a spacecraft, resulting in a resilient network able to mitigate and work around hardware failures onboard satellites. Each satellite incorporates a degree of redundancy previously seen only on far larger satellites, and is designed with longevity in mind. The network as a whole also protects against network-wide unreliability as a result of the failure of a single satellite - in the intended constellation, most regions, especially those with a latitude near the inclination of the satellites (such as North America, Europe, Oceania, and much of Asia and South America) are covered redundantly, and even elsewhere, the "gap" caused when the only satellite visible to a user has failed is usually short - lasting only minutes or less before working satellites come into view.

For many users, a satellite failure would likely be noticeable only as a decrease in the network's coverage angle, while for those in the aforementioned near-inclination regions, it might not be noticeable at all. Finally, we would be able to rapidly and inexpensively replenish the network with new satellites, either newly-launched or simply moved into place if already available in a storage orbit.

Privacy and Security

How is using FemtoStar private when using it indicates that you are looking for privacy?

FemtoStar is not purely a "privacy" system - we believe it to be competitive with other mobile satellite options, and in all likelihood there will be plenty of FemtoStar users who aren't even aware of, much less interested in, its privacy features. We also believe there will be a number of FemtoStar terminals installed as a part of machine-to-machine data installations, as backup connections for enterprise networks, or as backhaul to community-run terrestrial networks. A user using it because of its privacy features is indistinguishable from any of these users.

Additionally, by this logic, using any privacy-respecting product, service, or system is counterproductive, as its use might indicate that you are looking for privacy. This isn't how nearly anyone actually thinks about protecting their privacy. Even if your threat model truly does require that you obscure even the fact that someone is using a system that could be used for privacy-respecting communications, FemtoStar still does substantially better than just about any other privacy-respecting communications network. For one thing, a FemtoStar terminal uses a substantially more directional antenna than any terrestrial mobile network, which means its transmitted signal is very weak in any direction but that of the satellite.

A user's traffic to the satellite is also is encrypted, and never includes a location, terminal identifier, user account, or any other identifying details about the user. The terminal never transmits when it has no session open with the satellite, and, unlike mesh network nodes, it cannot be made to transmit by the traffic of another user unless the terminal's owner has chosen to operate their own service over the network.

Don't FemtoStar's satellites have to know where I am, based on which beam I use?

In theory, to some extent, but in practice, not meaningfully. A FemtoStar satellite has only a handful of beams in use at any given moment, and the footprints within which these beams are usable are between 1000 and 4000 kilometers across each, depending on your coverage angle. In addition, knowing where "you" are, as opposed to just knowing the rough area in which one of the network's users is located, requires knowing who you are. As such, the satellite could determine that an anonymous session is within, for example, northern Europe, western North America, or eastern Asia, but not that it is in a particular country or city, and certainly not who that session belongs to.

You say geolocation-resistant - is it geolocation-proof?

We do not feel that we can promise that there is any two-way wireless communications system where it is truly impossible for an adversary to locate a transmitter given enough time to search for it on the ground. In particular, it is extremely difficult to prevent just about any transmitter from being detectable by a high-gain antenna at short range, no matter how directional or low-power the transmitter may be. However, we also believe that such a search would need to begin relatively close to any terminal it wanted to have a chance of finding, and that it would likely be complicated by the presence of more than one FemtoStar terminal in an area.

Additionally, there's the question of why finding terminals would be worthwhile to an attacker to begin with. Given that such an attack would almost certainly involve the rather labor-intensive task of traveling around an area of interest with a vehicle full of equipment looking for terminals that you cannot identify and cannot monitor the activity of, while also being unable to tell the difference between two intermittently-used terminals and one terminal which has moved, we do feel we can say that this attack is unlikely to fit into many threat models.

A FemtoStar terminal could theoretically function as a receive-only device if this is acceptable for the user's use case - in this configuration, it would likely be nearly impossible to geolocate, even with this sort of attack.

In short, we don't believe any transmitting device is truly geolocation-proof, but we do believe that geolocation of users can be made impractical for to perform at a large scale, and that its value to an attacker can be substantially diminished. On top of this, we do feel we can safely say that FemtoStar is substantially more geolocation-resistant than any currently-available two-way wireless communications system, and that it is likely that its geolocation-resistance could only be matched or exceeded by another satellite-based system including most or all of the same geolocation-resistance features.

What if the FemtoStar project is taken over by someone I don't trust?

The FemtoStar architecture does not require that you trust the FemtoStar Project, even to begin with. Because the user is not required to trust the FemtoStar network, in order for the FemtoStar Project, or or an entity who had taken it over, to meaningfully compromise the security of FemtoStar users, many core design elements of the network would need to be changed, necessitating, at minimum, a firmware update to user terminals to accomodate substantial protocol changes. A new update published without source code would be immediately suspicious, as would a new update where the newly-released source code disabled privacy features.

What if I don't trust whatever place the FemtoStar Project is run from?

See the above point. Even if a malicious government were to take over FemtoStar Inc., or some part of the development work under the FemtoStar Project, and attempt to surveil the network's users, they would be incapable of doing so without making changes that would be immediately obvious to users, and to our own developers in other countries.

What if the satellites themselves are attacked?

While we would never claim that it is impossible that a FemtoStar satellite could be compromised, either remotely or through physical attack, we believe the likelihood of this to be low for a number of reasons.

The most important point here is that FemtoStar satellites are not especially useful targets to an attacker. Due to not being a trusted part of the network, even if they themselves are fully compromised, they cannot be used to compromise the security of FemtoStar users, nor would they be much use as part of a botnet, nor would they provide an attacker with any additional utility in their intended purpose (communications) than would be available officially.

With regards to compromising the satellites from the ground, the satellite's onboard software is subject to intense scrutiny, including through formal proofs of critical components, and, given the relative simplicity of the FemtoStar protocol, presents a small attack surface.

In terms of physical security, while FemtoStar's placement of its infrastructure in orbit certainly grants it a degree of inaccessibility compared to terrestrial infrastructure, there are of course spacecraft which could conceivably reach a FemtoStar satellite, and an attack could be imagined which might either tamper with or replace it. However, tampering would require physical capture and substantial disassembly of the satellite, which is detectable and would result in the deletion of onboard keys, resulting in a tampered-with satellite being easily detectable from the ground (even if new software attempted to obscure this tampering), while a replacement satellite would lack the cryptographic keys of the satellite it replaced entirely.

If you truly want to assume that no attacker is off the table, then an attacker could opt to attempt to disable, capture, or destroy a satellite altogether. However, an attacker trying to make the network truly unusable would need to destroy or disable not just one satellite, but the bulk of the constellation, and any replacement satellites, and, presumably, would wish to do so in a way which obscured their involvement, a daunting task even for the largest possible adversaries. This type of attack is also immediately obvious (especially if the satellite is physically destroyed, resulting in the generation of orbital debris), and even this still does not result in an actual compromise (geolocation, identification, etc.) of FemtoStar users.