Inside Sollensium: Evaluating Sollensys' Double-Blockchain Approach to Data Resilience

The Business Problem: Protection Is Not Recovery

Cybersecurity programs commonly prioritize keeping attackers out. Identity controls, endpoint security, network segmentation, monitoring, and access restrictions all serve that purpose.

They cannot eliminate every possible compromise.

An organization also needs a defensible answer to a different question: what happens when an attacker gains access despite those controls?

The consequences depend heavily on what remains recoverable.

A company might possess multiple copies of its data, yet discover that those copies share administrative credentials, are reachable through the same compromised environment, or have been altered before the incident was detected.

In such circumstances, redundancy alone may provide less protection than expected.

Recovery planning must therefore address several distinct requirements:

• —Confidentiality: Preventing unauthorized disclosure of information.
• —Integrity: Detecting or preventing unauthorized changes to protected information.
• —Availability: Ensuring necessary information can be retrieved when required.
• —Recoverability: Reconstructing usable data and restoring dependent systems after a disruption.

These objectives overlap, but they are not interchangeable.

An encrypted archive may protect confidentiality while remaining unavailable because the required keys have been lost. A tamper-evident record may establish that information changed without providing a clean version to restore. Multiple copies may improve resilience while remaining exposed to the same administrative compromise.

CISA's ransomware guidance emphasizes protected backups, regular restoration testing, and recovery procedures precisely because restoring operations requires more than possessing a backup file.^[5]

Sollensium is worth examining in that context: as a proposed additional layer of archival integrity and recoverability within a broader business-continuity strategy.

What Sollensium Is Intended to Do

Sollensys describes Sollensium as a private double-blockchain system underpinning its Blockchain Archive Server.^[3]

The company's published architecture describes two distinct networks.^[1]

The first is a distributed file system blockchain associated with encrypted data fragments.

The second is a smart-contract blockchain associated with private-key fragments or other key-related information used in authorizing and reconstructing archived data.

The Blockchain Archive Server functions as an intermediary between existing organizational systems and the archival networks.

In Sollensys' description, data is copied into the BAS, encrypted, fragmented, and distributed. Reconstruction requires the relevant authorization and key-related information, allowing the archived material to be retrieved and reassembled.^[2]

This is a description of the architecture as represented by its developer. It is not an independent verification of its implementation.

The distinction is important because a diagram showing two separate networks does not disclose every security-critical detail.

Among the questions it leaves open are the precise cryptographic primitives, the management of key material, the separation of administrative privileges, the security of the nodes, and the circumstances under which an authorized recovery can be performed.

Those details determine whether the architectural separation provides the intended protection in practice.

Understanding the Two-Layer Design

The most useful way to evaluate Sollensium is to separate its underlying functions rather than treat double blockchain as a single security feature.

The archival data layer

The first layer is intended to hold distributed fragments of encrypted information.

Fragmentation can make an individual storage fragment less useful to an attacker, particularly when it does not contain enough information to reconstruct a complete file.

Encryption adds a separate confidentiality mechanism. Properly implemented encryption makes information unintelligible without the necessary cryptographic material.

Distribution may improve resilience by reducing dependence on a single physical or logical storage location.

But these properties depend on implementation.

Fragmentation alone is not encryption. Replication alone is not access control. Distribution does not guarantee availability if participating nodes, networking, authentication, or administrative systems share critical dependencies.

An architecture review should establish how fragments are produced, where they are stored, how their integrity is verified, and what minimum conditions are required to retrieve them.

It should also clarify what is actually stored in the blockchain ledger as opposed to an associated distributed storage system.

That distinction affects scalability, performance, data governance, and technical risk.

The authorization and key-related layer

Sollensys describes a second blockchain handling key-related information and reconstruction authorization.^[2]

Separating the information needed for reconstruction from the encrypted data it protects can establish a meaningful security boundary.

An attacker obtaining only encrypted fragments should not automatically be able to recover usable plaintext if the cryptographic controls and key management are sound.

However, this benefit does not arise simply because the key-related information resides on another blockchain.

A complete evaluation must determine how secrets are generated, protected, divided, recovered, rotated, and revoked.

It must also assess whether a compromised operator, administrator, recovery device, or application component could access both logical layers.

The architecture's security therefore depends on effective separation of trust and control, not merely separation of infrastructure.

The reconstruction process

Recovery is the moment at which these controls must work together.

The system must identify the correct archive version, locate enough valid fragments, establish authorization, recover the necessary cryptographic material, decrypt the information, verify its integrity, and deliver a usable result.

Each stage introduces operational dependencies.

A secure archive that cannot be reconstructed promptly may fail the business's recovery objectives. Conversely, a reconstruction mechanism designed for convenience can become a concentrated security risk if its privileges are excessive.

The most meaningful tests are therefore end-to-end recovery exercises—not demonstrations that individual fragments are unreadable.

What Blockchain Adds—and What It Does Not

Blockchain is often described in terms of immutability. In technical practice, a more useful starting point is resistance to unauthorized modification and the ability to detect changes under an established network model.

NIST's Blockchain Technology Overview describes blockchains as tamper-evident and tamper-resistant distributed ledgers. The strength and practical significance of those properties depend on the network's architecture and consensus arrangements.^[4]

In an archival system, such properties may help establish an auditable history of records or make unauthorized changes more difficult to conceal.

That can be valuable when integrity is a central requirement.

However, several questions remain separate from ledger integrity.

A blockchain cannot establish that an original file was accurate before it was archived. It cannot independently guarantee that an application's credentials will remain secure. It does not eliminate the need for operational controls, physical infrastructure, monitoring, incident response, or reliable key management.

Nor does blockchain provide universal protection from ransomware.

A ransomware attacker might target production systems, steal information before archival, compromise administrative credentials, or disrupt the infrastructure required for recovery.

A resilient archive may reduce the consequences of certain attacks. It does not necessarily prevent the attacks themselves.

The correct evaluation therefore concerns the system's complete threat model rather than a claim of inherent invulnerability.

Does Using Two Blockchains Necessarily Improve Security?

Not necessarily.

Two networks can create useful separation, but they can also create additional dependencies and management complexity.

The outcome depends on whether the second network establishes a genuinely independent security boundary.

Consider two contrasting designs.

In the first, archival data and reconstruction credentials use separate infrastructure but remain controlled by one highly privileged administrative identity. Compromise of that identity could undermine both layers.

In the second, different trust domains, tightly controlled authorization procedures, independent recovery controls, and audited key-management mechanisms prevent a single compromised component from authorizing reconstruction.

Both may be described as having two technical layers. Their security properties are substantially different.

For a business, the relevant questions include:

• —Can one compromised identity control both networks?
• —Are administrative privileges separated?
• —What prevents unauthorized reconstruction?
• —How are cryptographic keys protected and recovered?
• —What happens if a network or service becomes unavailable?
• —How are archived versions protected from authorized-but-malicious deletion?
• —Can recovery proceed if the original BAS appliance is unavailable?
• —What independent testing supports the claimed security properties?

These questions are not unique criticisms of Sollensium. They apply to any architecture that relies on distributed storage and separated cryptographic controls.

Without sufficient implementation evidence, the number of blockchains is not a reliable measure of system security.

The More Important Test: Recoverability

An archival product should ultimately be evaluated against the recovery outcomes an organization needs.

CISA recommends maintaining protected copies of critical information and regularly testing their availability and integrity.^[5]

NIST's Cybersecurity Framework 2.0 also treats recovery as an organizational function involving restoration priorities, responsibilities, validation, and communication.^[6]

These principles apply whether an organization uses conventional immutable backups, offline storage, distributed archives, or blockchain-based infrastructure.

For Sollensium, practical validation should include a controlled restore of representative workloads.

A useful exercise would examine whether the system can recover:

1. 01Individual files.
2. 02Large collections of files.
3. 03Application dependencies.
4. 04Required configurations.
5. 05Selected historical versions.
6. 06Data from a period before the simulated compromise.

It should also test failure scenarios, including loss of network connectivity, unavailable nodes, corrupted fragments, inaccessible recovery credentials, and compromised administrative access.

The organization should measure actual results against its recovery time objective (RTO) and recovery point objective (RPO).

RTO concerns how quickly a service must be restored. RPO concerns the maximum tolerable loss of data measured backward from a disruption.

Neither objective can be established from a product's architectural description alone.

A system may preserve data integrity and still fail a recovery-time requirement because of reconstruction throughput, missing application dependencies, or limited operational readiness.

That is why controlled restoration results are more persuasive than generalized promises of rapid recovery.

Sollensium Compared with Conventional Recovery Architectures

A business evaluating Sollensium should compare it against credible alternatives rather than against an unprotected server.

This comparison is conceptual. It does not establish that one approach consistently outperforms the other.

Conventional backup systems can already provide strong immutability, encryption, isolation, and tested recoverability.

Sollensium's potential differentiation must therefore be demonstrated through capabilities or operational results that matter beyond the fact that blockchain technology is involved.

Those results might concern independent verification, trust separation, archive integrity, or resilience against particular compromise scenarios.

Whether such benefits are achieved must be determined through technical evidence and testing.

Where a Double-Blockchain Archive Might Fit

The most plausible use case is an organization seeking an additional recovery layer for information that is difficult or costly to recreate.

Examples could include:

• —Historical business records.
• —Intellectual property.
• —Critical operational documentation.
• —Long-retention archives.
• —Selected system images.
• —Records shared across operational boundaries.
• —Information requiring strong change-detection controls.

The suitability of the architecture depends on retention requirements, access frequency, confidentiality, data volume, recovery objectives, and applicable legal obligations.

Not every workload belongs in a distributed archive.

Frequently updated transactional databases, latency-sensitive applications, and systems with strict deletion or retention obligations may present different challenges from static archival records.

In some circumstances, conventional storage with properly managed immutable backups will remain the simpler approach.

An organization should establish its requirements before selecting the underlying technology.

Five Questions a Business Should Ask Before Adoption

A technical demonstration is useful. A documented evaluation is better.

Before adopting Sollensium—or any comparable archival platform—an organization should require defensible answers to five questions.

1. What precise failure scenario does this solve?

Define the attacks and failures against which the archive is intended to provide protection.

Distinguish ransomware encryption, destructive deletion, unauthorized modification, credential compromise, service outage, and data exfiltration.

A product effective against one scenario may offer limited protection against another.

2. What evidence supports the security architecture?

Request a sufficiently detailed technical explanation covering encryption, key handling, administrative separation, node security, auditability, and reconstruction authorization.

Where available, examine independent security assessments and the scope of their testing.

Avoid treating proprietary architecture or confidential implementation details as automatic evidence of security.

3. Can we recover our actual systems?

Request a controlled restoration exercise involving representative organizational data.

Measure recoverability against documented recovery objectives.

Include conditions where supporting infrastructure is partially unavailable.

4. What is the ongoing operating burden?

Assess acquisition and subscription costs, integration work, network dependencies, support arrangements, retention management, monitoring, staff training, and recovery procedures.

Evaluate the full lifecycle rather than the archive's initial deployment alone.

5. What happens if the provider becomes unavailable?

Determine who controls the relevant cryptographic material, what export procedures exist, and whether the organization can recover its information without depending indefinitely on one vendor's operational availability.

Include contractual exit provisions and data-retention responsibilities in the assessment.

These questions apply to blockchain-based and conventional archival providers alike.

The Broader Business Implication

Sollensium illustrates something important about blockchain technology: its potential uses extend beyond financial transactions, token issuance, and cryptocurrency networks.

Distributed ledgers can participate in systems designed around auditability, shared trust, and data integrity.

However, the presence of blockchain does not determine whether those systems create better business outcomes.

The value arises when technical architecture addresses a specific operational requirement more effectively than plausible alternatives.

For Sollensium, the relevant requirement is not blockchain adoption. It is preserving recoverable, trustworthy information after a serious disruption.

The company's double-blockchain design presents a distinctive approach to separating archival data from reconstruction-related controls.

Whether that approach provides superior resilience in a particular organization remains a matter for documented technical evaluation, integration analysis, and realistic recovery testing.

That is the standard by which any serious business-continuity architecture should be judged.

Conclusion

The most interesting aspect of Sollensium is not the claim that two blockchains are inherently difficult to compromise.

It is the attempt to separate protected data from the mechanisms required to reconstruct it, while using distributed infrastructure to support archival integrity and resilience.

That design deserves consideration because it addresses a real organizational concern: an attacker may compromise production systems without necessarily compromising every independent recovery mechanism.

But design intent is not the same as demonstrated performance.

An enterprise deciding whether to adopt Sollensium should look beyond architectural labels and demand clarity on threat models, cryptographic controls, administrative separation, independent verification, restoration performance, and business continuity.

The relevant measure of success is straightforward.

When an organization needs its information back, can the system return complete, trustworthy, usable data within the time the business can tolerate?

A defensible answer to that question is worth more than any claim of technological invulnerability.