Executive Summary
SORA (SorachanCoin) is an independent blockchain project developed by IUEC Co., Ltd., a Japanese company. Development began in 2017, and the mainnet launched on August 6, 2018. Building on continued network operation, the project has expanded into storage diagnostics and data recovery, AI inference, and quantum-resistant technologies.
SORA's defining characteristic is the connection between cryptographic research, practical software, and real-world challenges. The SorachanCoin core on Layer 1 provides the foundation for transactions and network operation, while FromHDDtoSSD v3 on Layer 2 supports storage diagnostics and processing using AI-NFT. Findings from investigations into AI agent behavior are also informing the development of AI security.
This paper distinguishes existing operations and implementations, ongoing research, and future design directions. Introducing post-quantum cryptography (PQC) is an important step toward quantum resistance, with further evaluation covering key management, transaction structure, hashing, and network operation. For AI security, this paper similarly distinguishes current investigation and development from future designs for monitoring, control, and verification.
1. Origins and Objectives
SORA grew out of years of software development and practical data recovery work in Tokyo. A drive failure can make stored information inaccessible when it is needed, even when the information still exists. In cryptography and blockchain, it is likewise important to preserve records and make it possible to verify their provenance and the permissions governing their use.
These practical concerns led to development connecting storage diagnostic results, statistical information, AI inference, and blockchain records. Testing in the field, checking results, and incorporating findings into the next implementation are central to SORA's development approach.
The project's current objectives fall into three areas:
- Maintain the operation of an independent blockchain and update its cryptographic capabilities for the quantum computing era.
- Expand practical applications of AI and blockchain, particularly in storage diagnostics and data recovery.
- Develop technologies to detect suspicious AI agent behavior and actions beyond authorized permissions, and to manage access to information appropriately.
2. Three Challenges SORA Addresses
2.1 Maintaining the Verifiability of Records and Their Provenance
Diagnostic results and processing histories need to remain traceable over time, including when information was obtained and under what conditions. SORA addresses this challenge by combining blockchain recordkeeping with software that performs the actual processing.
Detecting changes to a record and verifying that its contents are factually correct are separate tasks. Preserving diagnostic methods and measurement conditions so that results can be checked again contributes to practical trust.
2.2 Updating Cryptography Over the Long Term
Assets and information intended for long-term storage require mechanisms that can accommodate changes in cryptographic technology. SORA is implementing and evaluating PQC while developing an environment that supports migration from conventional transaction formats to formats intended to provide quantum resistance.
Signatures, hashes, key storage, and consensus each serve different purposes. Introducing a particular signature scheme alone does not establish the security of an entire network. SORA evaluates these components separately.
2.3 Managing the Scope of AI Actions
When AI operates on files or uses external tools, the scope of its assigned task must align with the operations it is actually permitted to perform. Preventing unexpected information access or external transmission requires mechanisms that check the actions performed, as well as the AI's output.
SORA investigates AI agent behavior and combines those findings with knowledge gained through quantum-resistance and cryptographic development to advance AI security.
3. Overall Architecture: The Roles of L1 and L2
SORA uses an architecture in which L1 and L2 run different programs. The independent blockchain and the applications used in the field are developed as separate executables.
| Component | Primary Role | Position within the Project |
|---|---|---|
| L1: SorachanCoin core | SORA transactions, wallets, PoW and PoS, and cryptographic functions | The foundation for continued network operation |
| L2: FromHDDtoSSD v3 | Storage diagnostics, AI inference, AI-NFT, statistical processing, and ownership management | The connection between practical software and blockchain |
| AI security | Investigation of AI agent behavior, detection of permission violations, and management mechanisms | An extension under investigation and development |
| Collaboration with SS256 | Research communication, community engagement, and sharing AI security initiatives | A direction for collaboration between projects |
In this paper, L2 refers to SORA's application layer, centered on FromHDDtoSSD and its use of blockchain functionality. Official development documentation describes an architecture that uses full nodes and improves startup and processing efficiency for practical software. [3] This paper does not define this L2 as a particular rollup or proof scheme.
4. L1: The Foundation for Continued Operation
4.1 Basic Design
SORA's L1 is an independent blockchain combining PoW and PoS. The following are basic design values presented in the official published specifications. Future changes are treated as network updates. [1]
| Item | Published Specification or Project Information |
|---|---|
| Name and ticker | SorachanCoin / SORA |
| Start of development | 2017 |
| Mainnet launch | August 6, 2018 |
| Consensus | PoW / PoS |
| PoW algorithm | Scrypt |
| Designed supply | 8,000,000 SORA |
| Target block interval | Approximately 3 minutes |
| Premine | 860,000 SORA |
The native coin, SORA, is used for L1 transactions and network participation. PoW and PoS rewards follow network rules. The issuance design, actual circulating supply, and rewards received by individual users are treated as distinct matters.
4.2 Wallets and Addresses
The wallet incorporates RapidSync to reduce synchronization time and an HD wallet with a 16-word recovery phrase. These features improve the usability of synchronization, recovery, and key management for both everyday use and long-term storage.
Official usage documentation describes conventional ECDSA addresses beginning with S, sora1 addresses incorporating PQC, and cipher1 addresses for encrypted communication. Balances for conventional and sora1 formats are managed separately, with transfers supported between the two formats. [2]
These address formats represent functions within SORA. The appearance or string format of an address alone does not establish asset compatibility with another blockchain.
5. PQC: Implementation and Ongoing Quantum-Resistance Research
5.1 Development History
SORA began developing quantum-resistant technologies in 2020 and implemented quantum-resistant functionality in its core in 2024. Earlier development materials use the name SORA-QAI. In line with the current presentation of the project, this paper organizes the discussion around PQC.
PQC is a general term for post-quantum cryptography. SORA's distinctive work lies in integrating PQC into transaction formats, wallets, signature processing, and operations, and evaluating those implementations. The existence of general PQC standards does not imply certification or completed validation of SORA's specific implementation. [5]
5.2 The Roles of PQC and Schnorr Signature Aggregation
SORA combines mechanisms intended to provide quantum resistance with improvements in signature-processing efficiency. Schnorr signature aggregation is positioned as a function related to more efficient processing of multiple keys and signatures.
| Component | Role in This Paper | Principal Evaluation Topics |
|---|---|---|
| PQC-based components | Aim to resist attacks using quantum computation | Schemes, parameters, threat models, and key management |
| Schnorr signature aggregation | Improve the efficiency of processing multiple keys and signatures | Aggregation procedures, key handling, and rejection of invalid signatures |
| Combined transaction format | Verify transaction validity as an integrated whole | Binding mandatory verification conditions, exception handling, and compatibility |
Conventional Schnorr signatures over elliptic curves cannot themselves be treated as PQC. BIP 340, a reference specification for Schnorr signatures, also defines a signature scheme over secp256k1. [6] Evaluating SORA transactions as a whole requires examining the role of each component and the mandatory verification conditions.
5.3 Implementation and Security Evaluation
Official usage documentation also positions quantum resistance as an area of ongoing experimentation and evaluation. [2] Introducing PQC and proving security against every quantum attack are distinct matters.
SORA continues to examine scheme extensions, signature size, processing time, management of key material, and coexistence with legacy formats. When maintaining compatibility, an important evaluation question is which nodes enforce the new verification conditions. Introducing cryptographic functions and applying them across the network are addressed separately.
6. L2: Practical Applications through FromHDDtoSSD v3
6.1 Starting with Storage Diagnostics
FromHDDtoSSD v3 is SORA's L2 software, connecting storage diagnostics with AI inference. Distributed as standalone software, it brings blockchain applications into concrete tasks such as assessing drive health and predicting failures. [4]
Diagnostics handle drive responses, read status, sector conditions, and statistical information. Different methods, including full scans, statistical scans, and time-saving scans, are used according to the diagnostic objective to assess storage condition.
An important consideration is the relationship between repeatedly placing load on areas with read problems and securing the data that can still be retrieved. By combining identification of failure indicators, reduced access to at-risk areas, and recovery assistance, the software aims to adapt processing to the drive's condition.
6.2 The Role of AI-NFT
Within SORA, AI-NFT is an initiative connecting AI inference, statistical processing, and ownership management with blockchain functionality. The project is developing structures that help identify and manage information handled by AI and trace processing results.
The objects managed as NFTs, the actual drives and stored data, and the permissions held by AI models each need to be clearly defined. Ownership of an AI-NFT is not equated with permission to view or transfer a user's stored data. Permission scopes are defined together with application-level management.
6.3 The Diagnostic, Inference, and Review Process
| Stage | Main Processing | Information to Check |
|---|---|---|
| 1. Status acquisition | Obtain drive information and read status | Target device, diagnostic conditions, and available information |
| 2. Analysis | Perform statistical processing and AI inference | Signs of anomalies, at-risk areas, and the basis for inference |
| 3. Operational decision | Select whether to continue diagnostics, avoid areas, or provide recovery assistance | Drive condition and the purpose of the task |
| 4. Results management | Associate processing results with AI-NFT and related functions | Identification of the target, management scope, and results history |
| 5. Review | Compare measured results with inference | Misclassifications, retrieval results, and areas for improvement |
This table is a conceptual overview of L2 processing. Functions available in individual product releases, information storage locations, and items recorded on-chain follow their respective implementation specifications.
6.4 Use Cases
Intended use cases include PC repair, drive selection, maintenance inspections, and data recovery. In addition to HDDs and SSDs, USB-connected drives and SD cards are among the targets whose field data can inform analysis.
AI predictions are improved through comparison with actual measurements. The relationship between the risk indicated by a model and the failures or read errors that actually occur is examined to evaluate predictive effectiveness. The technology is developed to support decision-making, without assuming that every failure can be predicted or every piece of data recovered.
7. Security for AI Agents
7.1 From Investigation to Development
While investigating AI agent behavior, SORA is examining the relationship between the scope of instructions and actual access to information. This investigation is the starting point for developing technologies that detect suspicious behavior and access beyond the scope of instructions.
The following monitoring, control, and recordkeeping architecture outlines future design directions. It does not indicate that every function is already implemented in a product.
7.2 Matching Permissions to Actions
The central design objective is to reconcile the task instructions given to AI with the operations it is actually permitted to perform. Reading, writing, external transmission, and tool execution are treated separately, with clear definitions of the targets and the scope of operations.
| Design Area | Intended Function | Evaluation Question |
|---|---|---|
| Access to information | Compare permitted targets with actual access | Can access beyond the scope of instructions be detected? |
| Writing and modification | Check the target and scope of changes | Can modifications beyond granted permissions be prevented? |
| External transmission | Manage destinations and the scope of transmitted content | Can unintended disclosure of information be detected? |
| External tools | Check tool permissions and executed operations | Can unexpected routes for performing actions be managed? |
| History | Associate instructions, permissions, and results | Can the sequence of events be reviewed afterward? |
The intended architecture checks operations within the execution environment that actually grants access, instead of relying solely on the AI's own account of its actions. Connecting monitoring results with controls such as stopping or restricting operations requires integration with the environment running the AI.
7.3 Connecting with Blockchain
Blockchain is being considered as a recordkeeping foundation that supports detection of changes to histories and verification of provenance. Runtime access control is connected to permission management in the operating system, applications, and tools. Recorded histories provide material for reviewing what was executed and on what basis.
Recording AI instructions, user files, or secret information directly on a public chain may conflict with the goal of protecting information. Future design work therefore includes architectures that manage necessary information within the execution environment and use summaries or references for verification. Record formats, signature schemes, and viewing permissions will be defined individually.
8. Information Protection and Verifiability
Both storage diagnostics and AI security may involve access to user information. Distinguishing the scope of information acquired, used for analysis, and shared is a fundamental design requirement.
For verification of diagnostic results and operation histories, the aim is to make it possible to check the identity of the target, acquisition conditions, the software or model used for processing, and the state of permissions. Mechanisms for checking record integrity are combined with mechanisms restricting access to personal and confidential information.
Public records have limits in what they can establish. Processing outside the recorded scope and information acquired before the verification point require observation on the device or software side. These boundaries are made explicit to clarify what a record can establish.
9. SHA-256 Research and Cryptographic Updates
During the development of quantum-resistant technologies for SORA, the project began investigating the internal structure of SHA-256. It refers to the patterns it independently identified as “imprints” and continues to document reproduction procedures and interpretations.
This research presents computational observations, the conditions under which those observations can be reproduced, and their interpreted meaning separately. The project's interpretations of dates and place names are treated as part of its research narrative, distinct from a claim that the cryptographic designers' intentions have been conclusively established.
Evaluating cryptographic security requires specifying the property under examination, such as collision, preimage, or second-preimage resistance, and presenting attack procedures, required computational resources, and comparisons with existing approaches. The existence of reproducible patterns and the feasibility of a practical cryptographic attack are separate subjects of evaluation.
Alongside PQC support for signatures, SORA plans to research hash updates, including approaches involving SHA-3. Signature-scheme updates, hash updates, and changes to the PoW and PoS configuration are each pursued while examining their impact on the network.
10. The Roles of SORA and SS256
SS256 (Satoshi is SHA-256) emerged from efforts to communicate SORA's research. Through tokens issued on Ethereum and BNB Smart Chain, it advances research communication and community engagement.
| Item | SORA | SS256 |
|---|---|---|
| Foundation | An independent L1 blockchain | Tokens on Ethereum / BNB Smart Chain |
| Principal role | Network operation, quantum resistance, L2, and technology development | Research communication, a commemorative token, and community engagement |
| AI security | Investigation and technology development | Plans to share SORA's initiatives |
The projects plan to share SORA's AI security initiatives with SS256 and broaden activities connecting AI and Web3. The scope of shared technologies and services will be specified as implementation and operations progress.
SORA and SS256 are distinct assets and operate through mechanisms on different networks. Exchange functionality, bridges, or identical rights and terms of use are not established solely by the collaboration described in this paper.
11. Expansion from Tokyo toward Texas
SORA has built its development and operational experience in Tokyo, Japan. Based on that technology and experience, the project aims to expand its activities with Texas as a focal point.
Expansion toward Texas in this paper is a future direction. Details of the operational location, development organization, the entities or activities to be registered, and the timing of any transition will be announced as they become concrete. This does not indicate that a corporate relocation to Texas or registration there has already been completed.
Changes to the geographic location of project activities and technical updates to the blockchain are treated as separate processes. The scope of expansion will be clarified while emphasizing continued network operation, users' key management, and existing transaction histories.
12. Development Status and Roadmap
12.1 Current Position
| Area | Status in This Paper | Future Focus |
|---|---|---|
| L1 and PoW / PoS | Continued mainnet operation | Stable operation and evaluation of updates |
| RapidSync and HD wallet | Introduced functions | Practical usability of synchronization, recovery, and key management |
| PQC and sora1 | Functions implemented; evaluation continues | Transaction structure, key management, and migration |
| Schnorr signature aggregation | Introduced function | Efficiency and verification conditions during aggregation |
| FromHDDtoSSD v3 and AI-NFT | Practical areas developed through software delivery and implementation | Improvements to diagnostics, inference, and recovery assistance |
| AI agent security | Under investigation and development | Action monitoring, permission management, and history verification |
| Sharing AI security with SS256 | Future direction | Defining deliverables and terms of use |
| Texas expansion | Future direction | Defining the scope of activities, organization, and timing |
12.2 Existing Plans and Targets
Previous plans set a target of advancing migration to the sora1 format by 2027 and targets for hash updates and migration to Staking - PQC by 2030. Implementation of the sora1 functions themselves is distinguished from completing migration across the usage environment.
Existing policy also aims for an update within one year after a practical hash collision is confirmed. This is a target for accelerating vulnerability assessment and preparation for updates; it does not indicate that such a collision has already been confirmed. Implementation decisions will take into account the scope of the update, evaluation results, and node readiness.
No fixed completion dates for AI security or Texas expansion are set in this paper. The relevant functions, evaluation results, and availability dates will be announced as implementation and organizational arrangements become concrete.
13. Evaluation Approach
SORA incorporates findings from field use into subsequent development. Published evaluations will emphasize clear testing conditions and measurement targets so that results can be checked again.
| Area | Items to Present in Future Evaluations |
|---|---|
| PQC | Selected schemes and parameters, signing and verification conditions, handling of invalid input, key management, and compatibility |
| Wallets | Synchronization and recovery conditions, target versions, and measurement environments |
| L2 and AI inference | Target drives, input information, model and processing versions, and comparisons between predictions and measurements |
| AI security | Examples of permitted and prohibited actions, detection rates, false positives, time to stop an operation, and areas outside monitoring coverage |
| Record verification | Recorded items, signers, recording times, and conditions under which changes or omissions can be checked |
These are items to be clarified through future evaluation. This paper alone does not establish a security proof, completion of an external audit, or confirmation of particular performance figures. When detailed technical specifications are published, they will be linked to the corresponding implementation versions and evaluation materials.
14. Outlook
SORA will connect independent blockchain operation, storage diagnostics and data recovery, quantum-resistant technologies, and AI security within its development activities.
Knowledge gained from L2 use in the field will inform technology development, while cryptographic research will be developed into usable functions. As autonomous AI work expands, SORA aims to create an environment in which the scope and history of AI actions can be examined.
Development that began in Tokyo will be carried forward into the next phase of expansion centered on Texas. Advancing research into practical applications while maintaining continued network operation remains SORA's guiding approach.
Appendix A: Glossary
| Term | Meaning in This Paper |
|---|---|
| L1 | The foundation for SORA transactions and network operation |
| L2 | SORA's application layer, centered on FromHDDtoSSD |
| PQC | Cryptographic technologies intended to resist attacks by quantum computers |
| SORA-QAI | A name used in earlier development materials for SORA-specific transaction and cryptographic functions |
| AI-NFT | SORA's initiative connecting AI inference, statistical processing, and ownership management |
| Schnorr signature aggregation | A signature function related to more efficient processing of multiple keys and signatures |
| RapidSync | A function that reduces wallet synchronization time |
| HD wallet | A wallet that manages keys hierarchically based on a recovery phrase |
| Staking - PQC | A future migration direction centered on staking and PQC, described in the existing roadmap |
Appendix B: Sources and Scope
This paper is an overview compiled from previous project explanations and the introduction and expansion direction organized in October 2026. Official materials are cited as supporting sources for the relevant functions and published specifications. Earlier publications are not treated as the current specifications for every function.
This paper does not define the complete mathematical specifications of the PQC schemes, transaction byte formats, consensus-change procedures, or AI security APIs and log formats. These are subjects for the corresponding implementation and evaluation materials.
[1] IUEC, “About SorachanCoin” - Published initial specifications and supply design.
https://www.iuec.co.jp/sora/sorachancoin - iuec/
[2] IUEC, “How to Use the SORA Blockchain [Quantum-Resistance] Core” - Addresses, balance management, and the evaluation stage of quantum resistance.
https://www.iuec.co.jp/how-to-use-sora-qai
[3] IUEC, “Regarding LoadBlockIndex, In the SORA L2 Blockchain (FromHDDtoSSD)” - L2 full-node use and startup processing.
https://www.iuec.co.jp/sora/regarding-loadblockindex-in-the-sora-l2-blockchain-fromhddtossd/
[4] IUEC, “FromHDDtoSSD v3 Download” - Availability of the L2 software.
https://www.iuec.co.jp/fromhddtossd2s/v3_0_dl.html
[5] NIST, “Post-Quantum Cryptography FIPS Approved” - Reference material on general PQC standards. It does not establish certification of SORA.
https://csrc.nist.gov/News/2024/postquantum-cryptography-fips-approved
[6] BIP 340, “Schnorr Signatures for secp256k1” - A reference specification for conventional Schnorr signatures. This does not imply that SORA adopts an identical specification.
