Europe Unveils RLV C5 Reusable Rocket Concept as a Potential Competitor to SpaceX Starship
The first full-scale launch of Starship in April 2023 ended in an explosion, yet it successfully demonstrated that the massive integrated vehicle could lift off. Eighteen months later, SpaceX returned the Super Heavy booster to the launch site and caught it with the mechanical arms of the launch tower. After the fifth test flight, discussions about a fully reusable super-heavy launch system no longer seemed like distant engineering fantasy.
Starship is designed to deliver more than 100 tons to low Earth orbit while returning both stages for rapid reuse. Although SpaceX has not yet reached the advertised performance figures and continues iterative development, the sheer scale of the project is forcing other nations to reassess their own rocket programs. The question is shifting from whether Starship will transform the space industry to what the appropriate competitive response should be.
An independent assessment of the American rocket’s capabilities was conducted by the German Aerospace Center (DLR). Researchers avoided relying solely on published SpaceX specifications and instead reconstructed flight parameters from publicly available video footage of the first four integrated flight tests.
Specialists extracted telemetry data from the broadcasts and analyzed the vehicle’s motion on a second-by-second basis. Velocity, altitude, acceleration, and other available parameters formed the foundation of a dedicated simulation model. The results were then compared against actual flights to validate how accurately the model represented booster and ship performance.
The calculations showed that the current fully reusable version of Starship could theoretically deliver approximately 59 tons to low Earth orbit. This figure is close to the capability of Falcon Heavy in expendable mode when side boosters and the center core are not recovered.
The number is noticeably lower than the frequently cited 100-ton target, but it applies to an early configuration that has already flown. SpaceX is progressively increasing propellant capacity, upgrading to Raptor 3 engines, and refining the heat shield. Consequently, future variants are expected to deliver substantially higher performance than the initial prototypes.
The next-generation Starship will feature enlarged propellant tanks and higher-thrust Raptor 3 engines. According to the DLR model, a fully reusable system could lift around 115 tons to low Earth orbit, while an expendable configuration could reach 188 tons.
In expendable mode, the new Starship would surpass Saturn V, which sent American crews to the Moon. However, such comparisons reveal only one aspect of the design. SpaceX’s primary bet lies not in a single massive payload but in rapid reuse of both booster and ship.
Full reusability makes Starship extremely heavy. The vehicle requires heat-shield tiles, extra propellant for landing burns, a reinforced structure, and systems rated for multiple flights. Each of these elements reduces the mass available for payload compared with an expendable architecture.
In the same DLR study, researchers proposed a European alternative named RLV C5. The concept also belongs to the super-heavy class but does not attempt to recover the entire vehicle. Only the winged booster is designed for reuse; the upper stage remains expendable.
The booster design draws on work from the SpaceLiner program, which has studied hypersonic passenger vehicles in Europe for many years. RLV C5 inherits the winged shape and horizontal atmospheric return, although the vehicle will not perform a conventional runway landing.
After atmospheric entry, the booster will transition to gliding flight and rendezvous with a large subsonic aircraft. The aircraft will capture the booster in flight and tow it to a landing site. While this recovery method exists only in simulations, it eliminates the need for landing engines and reserve propellant.
Starship solves the same problem differently. Super Heavy flips after stage separation, reignites engines, returns to the launch site, and is caught by tower arms. The ship also performs a vertical landing after re-entry.
The European concept uses liquid hydrogen and liquid oxygen, whereas Starship burns methane and oxygen. Hydrogen provides higher specific impulse, allowing more efficient use of propellant mass. Methane is easier to store and its higher density reduces tank size; SpaceX also plans to produce methane on Mars from local resources.
These differing choices become evident when comparing vehicle mass. Starship will weigh more than three times as much as RLV C5 at liftoff. The American system carries equipment to recover both stages and is sized for significantly heavier payloads. The European rocket sacrifices the upper stage but achieves better mass efficiency as a result.
According to DLR calculations, payload constitutes roughly 40 percent of the total mass Starship delivers to orbit; the remainder is structure, return propellant, and reusability hardware. For RLV C5, the payload fraction could reach 74 percent because the expendable upper stage requires no heat shield or landing systems.
These percentages do not imply that the European rocket will exceed Starship in absolute payload capacity. The American vehicle is far larger and will lift many more tons per launch. RLV C5 offers a more economical payload-to-structure ratio rather than maximum throw mass.
The two vehicles target different missions. Starship is being developed for large-scale lunar expeditions, Mars flights, delivery of oversized modules, and rapid satellite constellation deployment. Its enormous internal volume can accommodate payloads that exceed the fairing dimensions of current launchers.
RLV C5 aims to give Europe independent access to super-heavy lift without immediately developing a fully reusable system. The concept leverages existing SpaceLiner research and could serve as an intermediate step toward a future European vehicle with full reusability.
Nevertheless, the comparison remains unequal. Starship is already undergoing flight testing, with engineers validating engines, heat shields, stage separation, and booster recovery on actual hardware. RLV C5 exists only as a paper design. Realizing a prototype would require a dedicated European program, substantial funding, and years of development to master mid-air capture of a heavy booster.
Starship itself is still far from routine operations. During the fourth flight, the ship sustained significant heat-shield damage, particularly near the forward flap. The vehicle survived re-entry and achieved a controlled splashdown, yet SpaceX had to redesign the thermal protection system.
The economics of the project depend not only on recovering stages but on reusing them without lengthy repairs or extensive post-flight inspections. If refurbishment proves costly and slow, the promised reduction in launch cost will be far more modest.
SpaceX currently holds an advantage not only in vehicle performance but also in accumulated real-world flight experience. The European concept illustrates an alternative technical path, yet only a completed rocket can validate the calculations. Until then, RLV C5 will remain on paper while American engineers continue testing their solutions in flight and advancing at an accelerated pace.
Related articles
OAuth Authorization Server Built Without Storing User Profiles
The article details the evolution of an OAuth Authorization Server that deliberately avoids storing user profiles, relying instead on external identity providers for authentication. It addresses three core constraints: hundreds of dynamically created isolated APIs, a public SPA client without a BFF, and the inability of resources to query the AS on every request. The design separates concerns so the AS handles only clients, tenants, grants, audiences, scopes, keys, sessions, and token issuance while the Main API owns profiles and roles. Tokens are managed securely inside a Service Worker using a custom FedCM grant, eliminating races across tabs and reducing XSS exposure. The approach minimizes blast radius, simplifies compliance, and keeps the AS replaceable without affecting product domain logic.
Why a 202-Character License Key Uses ECDSA P-256 Instead of Ed25519 or RSA
A developer building offline license verification for a .NET desktop application evaluated Ed25519, RSA, and ECDSA P-256 before selecting the last option. The decision was driven by the requirement for zero external dependencies, keys short enough for manual entry from email, and support for key rotation without breaking existing licenses. Although Ed25519 offers faster verification and a smaller public key, it is absent from System.Security.Cryptography in both .NET 8 and .NET 10, with API approval only targeted for version 11. RSA-2048 produces signatures too long for practical use, resulting in a 571-character Base32 string that users would find cumbersome. ECDSA P-256 with SHA-256 delivers a fixed 64-byte signature that becomes a manageable 202-character key when encoded in Base32, while remaining fully available in the runtime. The article also covers performance measurements, the risks of ECDSA nonce generation, and the deliberate choice of the IEEE P1363 signature format to guarantee fixed-length output.
Pilcrow Publishes Free Comprehensive Guide on Web Authentication
Author Pilcrow has released a detailed, ad-free handbook covering authentication and authorization practices for web applications. The resource draws on personal experience and includes practical examples in JavaScript and Go. It examines password-based methods, email verification, multi-factor authentication, passwordless flows, and passkeys while highlighting associated risks and usability trade-offs. The book also provides in-depth guidance on session management, token security, expiration policies, and email address handling as account identifiers. Recommendations emphasize choosing methods that match application security requirements and user expectations. Additional context is given on OWASP resources and community support channels.
redb 3.4.0 Adds Replay Checkpoints, Shared Runtime Layer and Declarative Secrets Handling for .NET Ecosystem
redb 3.4.0 delivers operational improvements for the .NET integration platform that includes typed storage over Postgres, MSSQL and SQLite, the redb.Route engine modeled after Apache Camel, the Tsak runtime with dashboard and clustering, and redb.Identity for OIDC and OAuth 2.1. The release focuses on post-deployment resilience with replay checkpoints that capture message state at named points inside routes, allowing safe re-execution of downstream steps without duplicating side effects. A shared runtime layer moves framework assemblies into a separate Libs/shared directory so that individual DLLs can be replaced without rebuilding or redeploying the entire Tsak or Identity packages. Secrets are now declared with a [Sensitive] attribute on endpoint options, ensuring URIs containing passwords or keys are sanitized before they reach logs, metrics or health checks. Additional controls include role-based access to management APIs, persistent audit trails and cryptographic signing of dynamically loaded modules. All Pro features remain free on the entire 3.x line with no licensing server required.