# Introduction to TransferChain Welcome to TransferChain! TransferChain enables users to store, process and distribute their data while ensuring its privacy and security. # Why TransferChain TransferChain for Developers ### Introduction to TransferChain Ecosystem Businesses and consumers alike increasingly prefer cloud services to store, process, and distribute data online. However, the current cloud storage practices essentially entail that data is entrusted to a third party without any previous trust-based connection. The need and popularity of the cloud has grown significantly in the past few years. Cloud Service Suppliers provide easy-to-use, cost-effective methods for storing all kinds of information, as well as data sharing between users; however, they still lack security and privacy. The ever-expanding quantity of precious and confidential data for individuals and corporations must be protected, as its irreversible loss or illegal transfer to third parties has unacceptable consequences. ### **Privacy & Security for Everyone** Individuals and particularly companies are becoming reluctant to rely on conventional cloud storage facilities to transfer and store their information, as they are increasingly concerned about losing possession of it. Ceaseless attacks on corporations across countless sectors have only exacerbated these concerns. Users want to ensure that the data uploaded into the cloud will only be available to themselves and to persons whom they explicitly authorized. Neither the provider nor any unauthorized third parties, be it potential hackers or innocent passers-by, should be able to access the user’s private and confidential information. Furthermore, clients often maintain documents containing sensitive information about their companies such as designs, patents and trade secrets, which are vulnerable to industrial espionage. The damage to the firm’s business resulting from any unauthorized disclosure of such sensitive information can be severe and irreversible. ### Our Team & Philosophy TransferChain team, being aware of the expanding need of the cloud systems, has focused primarily on the security flaws of the existing Cloud Service Supplier companies. Being experts on Blockchain technology, TransferChain team have successfully developed a unique game changer cloud storage system, which guarantees security, necessary integrity and privacy of all transferred and stored data. TransferChain cloud storage system shall enable the consumers, private and public corporations to store, process and distribute their private and confidential data without compromising their privacy and security. All this is accomplished by using our innovative platform, which is user-friendly, cost-effective and most importantly hacker free, thanks to using the most advanced Blockchain technology with the incorporation of the unique data storage architecture and the highest industry level encryption systems. # Who is using TransferChain Some business use cases for TransferChain ### Examples for Areas of Use **Sales & Marketing:** In the dynamic world of sales and marketing, efficient communication and document exchange are paramount. Whether you need to send or receive marketing content to collaborate with external partners or share business proposals with potential clients, our secure platform ensures that your confidential information remains protected. With our robust features, you can streamline your sales and marketing efforts, all while maintaining the highest level of data security. **Human Resources:** Human Resources (HR) departments deal with a wealth of sensitive personal information. Ensuring that this data is handled with the utmost care and compliance is essential, especially in the era of strict data protection regulations like GDPR. Our platform provides a secure environment where HR professionals can store and manage personal data while adhering to GDPR guidelines, ensuring the privacy and confidentiality of employees and applicants. **Legal:** The legal industry often involves sharing confidential documents and information with external parties, such as clients, opposing counsel, or expert witnesses. Our platform simplifies this process while maintaining the highest level of security and confidentiality. You can confidently transfer confidential documents, contracts, and legal materials, knowing that your sensitive information is protected. **Executives:** Top-level executives need a secure and private channel for communication. Our platform offers message confidentiality, allowing executives to exchange sensitive information, strategic plans, and confidential discussions with each other without the risk of data breaches or leaks. Trust in the security of your communications, and focus on making critical decisions to drive your organization forward. **IT & Financial:** In the world of IT and financial management, transparency and accountability are essential. Our platform facilitates transparency across departments by providing detailed activity logs. This transparency allows you to monitor and track crucial transactions, system changes, and IT activities, ensuring that your organization operates smoothly and securely. **R\&D:** Research and Development (R\&D) departments handle classified information and sensitive data critical to innovation and competitive advantage. Our platform offers a secure environment to store and manage this invaluable information. With advanced encryption and access controls, you can safeguard your R\&D data, collaborate effectively within your team, and protect your intellectual property from unauthorized access or leaks. #### WEB3 SDKs are important for Web3 because they make it easier for developers to build decentralized applications (dapps). Dapps are more secure, transparent, and immutable than traditional web applications. SDKs can save developers time, improve security, increase compatibility, and simplify debugging. Here are the key points in a shorter format: * SDKs make it easier to build dapps. * Include security features to reduce vulnerabilities and ensure robustness. * Simplify interaction with blockchain protocols, eliminating complexity for developers. * SDKs can save developers time, improve security, increase compatibility, and simplify debugging. # About About TransferChain ### About TransferChain TransferChain creatively disrupts the already highly dynamic markets of cloud storage and cybersecurity. The innovative solutions offered by TransferChain strike the optimal balance between privacy, security and speed, unleashing the full potential of powerful concepts such as blockchain, cryptography and cloud. Versatile and competitive plans combined with custom-tailored pricing arrangements, TransferChain is here to make cloud storage and cybersecurity much safer, scalable, user-friendly and cost-effective. # Client SDKs & Network Navigate through SDKs # Getting Started Building Privacy & Security Get started building Application over TransferChain architecture. # Introduction to TransferChain SDKs & Network Intro to TransferChain SDK ## High-level Overview ### What is TransferChain SDK Software Development Kits (SDKs) are indispensable tools in modern software development. These toolkits provide developers with a comprehensive package of resources, including libraries, APIs, documentation, and sample code, designed to simplify and accelerate the application development process. In this exploration of SDKs, we'll uncover their core components, their importance in the software development landscape, and the numerous advantages they offer to developers and businesses. Join us as we delve into how SDKs foster innovation, reduce development time, and empower developers to create with ease. TransferChain SDK offers unique concept where users can build their applications over our infrasturcture where they can get creative on specific needs of use. ### Lack of Privacy Pushed Us to Build The lack of privacy in the digital age has been a significant driver for the development of privacy and security applications. Several factors have contributed to this push: * **Digitalization of Information:** With the increasing digitization of personal information, financial transactions, and communication, there's been a growing concern about the security and privacy of this data. People are more aware of the potential risks associated with online activities. * **Data Breaches and Cyberattacks:** High-profile data breaches and cyberattacks have become common headlines. These incidents have exposed sensitive information of millions of individuals, highlighting the vulnerability of personal data. * **Invasive Data Collection Practices:** Companies and organizations have become adept at collecting vast amounts of data about individuals, often without their explicit consent. This has raised concerns about how this data is used, shared, and stored. * **Government Surveillance:** Revelations about government surveillance programs, such as the NSA's PRISM, have eroded trust in online privacy. People have become more aware of the extent to which their digital activities may be monitored. * **Identity Theft:** The rise of identity theft and online fraud has made people more conscious of the need to protect their personal and financial information from malicious actors. * **Social Media and Personal Data:** Many social media platforms and online services rely on the collection of personal data for targeted advertising. Users are becoming more aware of the extent to which their online behavior is tracked. * **Legislation and Regulations:** Governments and regulatory bodies have recognized the need for enhanced privacy protections and have introduced laws such as the General Data Protection Regulation (GDPR) in Europe and the California Consumer Privacy Act (CCPA) in the United States. These regulations require organizations to implement stronger privacy measures. In response to these challenges, developers and companies have created a wide range of privacy and security applications and tools. These applications aim to: * **Protect Data**: Encryption tools and secure communication apps help individuals keep their data confidential and secure from prying eyes. * **Anonymize Online Activity**: Virtual private networks (VPNs) and privacy-focused web browsers help users mask their online identities and activities. * **Secure Authentication**: Two-factor authentication (2FA) and biometric authentication methods enhance the security of online accounts and reduce the risk of unauthorized access. * **Privacy Settings**: Many social media platforms and online services have introduced privacy settings that allow users to control what information is shared and with whom. * **Educate Users**: Privacy-focused apps and services often provide education and guidance on best practices for online privacy and security. Overall, the lack of privacy in the digital age has pushed us to prioritize the development and adoption of privacy and security applications to protect personal information and maintain a level of control over their digital lives. ### Getting started with the TransferChain SDK * Learn more about the architecture of a [TransferChain SDK ](https://transferchain.io/sdk) * Learn how to build an application-specific **Blockchain** from scratch and understand the dynamics of [using TransferChain](https://transferchain.io/). # FAQ Frequently Asked Questions & Answers ### TransferChain SDKs & Network Frequently Asked Questions * **What is a TransferChain SDK?** TransferChain SDK, or Software Development Kit, is a set of tools, libraries, and documentation that developers can use to integrate cloud security features and functionality into their applications or services. * **Why do I need a TransferChain SDKs & Network?** Using a TransferChain SDK helps ensure the security of your cloud-based applications and data. It provides pre-built security features, making it easier to implement best practices and protect your assets. * **Is the SDKs & Network compatible with all cloud platforms?** Compatibility may vary, but reputable SDKs often offer support for major cloud platforms like AWS, Azure, and Google Cloud. Be sure to check the documentation for specific platform compatibility. * **What security features does the SDKs & Network provide?** The features can vary, but typical offerings include encryption, authentication, authorization, access control and Blockchain integration. The specific features will depend on the project you choose. * **How do I integrate the SDKs & Network into my application?** The integration process depends on the SDK and programming language you're using. Refer to the SDK documentation for step-by-step instructions and code examples. * **Is the SDKs & Network open source?** Yes, TransferChain SDK is open source, while others are proprietary. Open-source SDKs often provide more transparency and customization options, but proprietary options may offer additional support and features. * **What level of support is available for the SDKs & Network?** SDK providers usually offer various levels of support, such as community support, email support. Review our support options from our Support Page and associated costs to determine the level that suits your needs. * **How often is the SDKs & Network updated?** We regularly updatw to address security vulnerabilities and improve functionality. Check the provider's update history and release notes to assess their commitment to maintenance. * **Is there a free trial available?** No, Free Trial is not available for TransferChain SDKs & Network. Please contact support for Free Use version of the product. * **What are the licensing terms and costs?** Licensing terms and costs can vary widely. Some SDKs are free to use, while others require a subscription or licensing fees. Review the pricing details provided by the SDK provider. * **How does the SDKs & Network handle compliance with industry standards (e.g., GDPR, ISO27001)?** TransferChain SDK meets most of the compliance requirements. It includes features like data encryption and access controls to assist with compliance. * **What** **happens if there's a security breach while using the SDKs & Network?** We do have protocols and resources in place to assist in the event of a security breach. Ensure you understand their incident response procedures and responsibilities. Please get in touch with us from secure channels. # Prerequisites Minimum Requirements Below, minimum requirements of TransferChain SDK & Network stated; * Golang: [Golang version 1.18 and above](#user-content-fn-1)[^1] * Javascript: Node.js version 18 and above * S4: Docker engine [^1]: # Python TransferChain Python SDK The TransferChain Infrastructure SDK for Python enables you to write code to manage TransferChain Infrastructure resources. ## Getting Started * To Start building the your product, please go ahead and check out * For further information on documentation and technical specs, please visit * API token and Secret needs to be requested from TransferChain via or please contact your customer success manager to obtain them. ## Initialize TransferChain ````python ```python # Import the TransferChain class from the SDK from transferchain.client import TransferChain # Initialize TransferChain tc = TransferChain() ``` ```` ## Add Master User ````python ```python # Import the TransferChain class from the SDK from transferchain.client import TransferChain # Initialize TransferChain tc = TransferChain() # When the SDK is initialized for the first time, creating a master user for that SDK is facilitated by using the 'add_master_user' operation. # Example: Create a Master User result_add_master_user = tc.add_master_user() master_user = result_add_master_user.data print(f"Master User created: {master_user.id}") ``` ```` ## Add User ````python ```python # Import the TransferChain class from the SDK from transferchain.client import TransferChain # Initialize TransferChain tc = TransferChain() # Example: Add a User result_add_user = tc.add_user() added_user = result_add_user.data print(f"User added: {added_user.id}") ``` ```` ## Get User ````python ```python # Import the TransferChain class from the SDK import os from transferchain.client import TransferChain # Initialize TransferChain tc = TransferChain() # Get TRANSFERCHAIN_USER_ID variable from env user_id = os.environ.get('TRANSFERCHAIN_USER_ID') # When any storage or transfer operation is desired, a user is required, and the 'get_user' method provides the necessary information related to the required user. # Example: Get a User user_id_to_get = user_id user_info = tc.get_user(user_id_to_get) print(f"User information: {user_info.id}") ``` ```` ## Restore Master User ````python ```python # Import the TransferChain class from the SDK from transferchain.client import TransferChain # Initialize TransferChain tc = TransferChain() # It writes the addresses of the master and user in the blockchain to the SDK database using the mnemonics found in the environment, and returns all transactions found to the SDK user. # Example: Restore a Master User result_restore_master_user = tc.restore_master_user() restored_master_user = result_restore_master_user.data print(f"Master User restored: {restored_master_user}") ``` ```` # Go TransferChain GoLang SDK The TransferChain Infrastructure SDK for Go enables you to write code to manage TransferChain Infrastructure resources. Coming Soon # TransferChain SDK Standard SDK Standards ### What is the purpose of an SDK standard? An SDK standard is a description of a protocol, standard, or feature that the TransferChain SDK is expected to use. It should list the required properties of the standard, explain why it was designed this way, and provide detailed technical specifications. The person who wrote the standard is responsible for getting it approved by the community and making sure that everyone agrees with it. An SDK standard must have the following sections: * A brief overview of what the standard is about. * A motivation for why the standard is needed. * A definition of any new terms used in the standard. * A description of the system model and properties. * A technical specification of the standard. * A history of the standard. * A copyright notice. The technical specification is the most important part of the SDK standard. It should include a detailed description of the API, the technical details, the backwards compatibility, any known issues, and an example implementation. The history section should list any documents that inspired the standard and a log of any changes that have been made to it. The copyright notice should state that the standard is licensed under the Apache 2.0 license. # Blockchain Read Node What is a Read Node? A **Read Node** is a specialized blockchain node we’ve developed to significantly accelerate **read operations**—such as fetching transaction data, verifying balances without compromising security or decentralization. Unlike traditional full nodes that handle both reading and writing (transaction validation and block propagation), a Read Node is **optimized purely for fast, efficient data retrieval** from the blockchain. How It Works * **No consensus burden**: Read Nodes are not involved in consensus or block production, allowing them to skip computationally expensive tasks. * **Optimized indexing**: We’ve restructured how data is indexed and cached, enabling low-latency access to frequently requested information. * **Selective syncing**: Instead of syncing the entire chain state block-by-block, Read Nodes prioritize the portions of data that matter for your application's read-heavy workflows. #### Use Cases * Real-time dashboards or analytics platforms * Fast wallet balance checks and transaction lookups * Blockchain explorers * Backend services that need high-frequency access to on-chain data # WebSocket Client WebSocket Client in TransferChain SDK #### Overview The TransferChain SDK provides a **WebSocket Client** interface to enable real-time communication between clients and the TransferChain protocol. This is especially useful for applications that require instant notifications or updates #### Key Features * **Real-time updates**: Receive instant events as they occur within the TransferChain system. * **Secure channel**: All WebSocket communications are end-to-end encrypted using your TransferChain session keys. * **Lightweight**: The client maintains a persistent connection without the overhead of constant polling. * **Pluggable**: Easily integrate into frontend apps, background services, or admin dashboards. #### How It Works 1. **Authenticate** using your TransferChain credentials. 2. **Initialize** the WebSocket client with your session token. 3. **Subscribe** to events (e.g., file received, password accessed). 4. **Listen** for event messages and react in your app. #### Security * All events are encrypted and bound to your session. * No third-party or public broadcast. Only authorized users can listen to relevant events. * Tamper-proof message verification using TransferChain’s cryptographic signatures. ``` ``` # Javascript TCABCI Read Node Javascript WebSocket Client TransferChain Fastest Read Network WebSocket Client\ Read Node Address: \ Read Node WebSocket Address: wss\://read-node-01.transferchain.io/ws ### Networks * medusa - v2 ### Installation ```bash $ npm i @tchain/tcabci-read-js-client ``` ### Example **Subscribe, Listen and Unsubscribe Example** ```javascript import TCaBCIClient from '@tchain/tcabci-read-js-client' const client = new TCaBCIClient() // OR const client = new TCaBCIClient([ 'https://read-node-01.transferchain.io', 'wss://read-node-01.transferchain.io/ws', ]) // OR // With addresses and WebSocket library and network name, version const client = new TCaBCIClient( [ 'https://read-node-01.transferchain.io', 'wss://read-node-01.transferchain.io/ws', ], WebSocket, 'transferchain', 'v1', ) client.Start() client.Subscribe(['', '']) client.SetListenCallback(() => { // If a transaction has been sent to your addresses, the callback you set here will be called. }) client.SetErrorCallback(() => { // If network errors will be called. }) client.SetCloseCallback(() => { // If server side close will be called. }) client.Unsubscribe() client.Stop() ``` # GO TCABCI Read Node Go WebSocket Client TransferChain Fastest Read Network WebSocket Client\ Read Node Address: \ Read Node WebSocket Address: wss\://read-node-01.transferchain.io/ws ### Networks * medusa - v2 ### Installation ```bash $ go get github.com/TransferChain/tcabci-read-go-client ``` ### Example **Subscribe, Listen and Unsubscribe Example** ```go package main import ( "log" tcabcireadgoclient "github.com/TransferChain/tcabci-read-go-client" ) func main() { readNodeClient, _ := tcabcireadgoclient.NewClient("https://read-node-01.transferchain.io", "wss://read-node-01.transferchain.io/ws", "medusa", "v2") if err := readNodeClient.Start(); err != nil { log.Fatal(err) } addresses := []string{ "", "", } if err := readNodeClient.Subscribe(addresses); err != nil { log.Fatal(err) } done := make(chan struct{}) // If a transaction has been sent to your addresses, the callback you set here will be called. readNodeClient.SetListenCallback(func(transaction *tcabcireadgoclient.Transaction) { // done <- struct{}{} }) <-done close(done) _ = readNodeClient.Unsubscribe() readNodeClient.Stop() } ``` # TransferChain SDK # S4 # Core Concepts & Architecture Full Technical Specification & Developer Integration Guide ## 1. What is TransferChain S4 **TransferChain S4 (Secure Simple Storage Service)** is a **self-hosted, Dockerized cryptographic storage enforcement layer** that exposes an HTTP SDK for secure object storage. S4 is **not a storage provider**. It is a **cryptographic + authorization layer** that sits between your application and storage infrastructure, ensuring that **no data is ever exposed in plaintext outside the trusted execution boundary**. ### Core Guarantees * Client-side and service-enforced encryption * Customer-controlled key custody (mnemonics-based) * Data fragmentation and distributed storage * Blockchain-backed immutability and auditability * Zero-knowledge architecture ## 2. High-Level Architecture ``` Client / Application | | SDK (encryption + signing + chunking) v TransferChain S4 (HTTP SDK - Docker) | | Encrypted + fragmented data v TransferChain File Operation Service | | Metadata (hashes, references) v TransferChain Blockchain (Medusa v2) ``` ### Trust Boundaries | Component | Trust Level | Notes | | ---------- | ------------ | ------------------------------ | | Client | Trusted | Holds keys | | S4 | Trusted | Handles crypto + orchestration | | Storage | Untrusted | Never sees full file | | Blockchain | Trust anchor | Immutable metadata | ### Critical Guarantees * S4 **never stores plaintext at rest** * Storage backends **never receive full files** * Blockchain **never stores data or keys** * TransferChain **cannot decrypt customer data** ## 3. Deployment Model * Runtime: Docker container * Stateless architecture State is externalized via: * `s4.yaml` (identity + key custody) * Storage backend (S3 / MinIO / etc.) * Blockchain ledger ### Supported Environments * Local development * On-premise * Private cloud * Regulated environments (finance, healthcare, defense) ## 4. Configuration File: s4.yaml This is the **core security file**. It defines: * Identity * Key custody * Storage routing * Blockchain connectivity * Runtime behavior ### ⚠️ Critical Warning `s4.yaml` contains: * mnemonics (root key) * organization identity Anyone with this file can access data. ## 4.1 Full Configuration ``` account: api: token: secret: url: https://connect.transferchain.io identifier: 0 mnemonics: uuid: fileoperation: host: https://file-operation.transferchain.io readnode: address: https://read-node-01.transferchain.io chain: name: medusa version: v2 wsaddress: wss://read-node-01.transferchain.io/ws verbose: false listen: true logformat: "json" version: v1 ``` ## 5. Configuration Deep Explanation ### 5.1 account (Root of Trust) This defines **identity + key ownership**. #### Fields * `token` / `secret` → API authentication * `identifier` → organization scope * `uuid` → global identity binding * `mnemonics` → **cryptographic root key** ### Mnemonics - BIP39 (Most Critical Part) * Generated during `/v1/account/init` * Used to derive: * encryption keys * signing keys * Required for: * restore * decrypt * ownership If lost → data is unrecoverable\ If leaked → partial compromise ### 5.2 fileoperation Handles: * encrypted uploads * encrypted downloads * deletion orchestration **Important:** * receives only encrypted fragments * cannot reconstruct files * has no key access ### 5.3 readnode (Blockchain Layer) Used for: * verifying transactions * audit trails * compliance Blockchain stores: * hashes * timestamps * proofs Never: * file contents * encryption keys ### 5.4 Runtime Controls | Field | Purpose | | --------- | --------------- | | verbose | debug logging | | listen | enable HTTP SDK | | logformat | JSON or text | | version | schema | ## 6. Environment Variables Recommended approach: ``` API_KEY= API_SECRET= IDENTIFIER= UUID= ``` Override `s4.yaml` dynamically. ## 7. Service Lifecycle ``` 1. Container starts 2. s4.yaml loaded 3. Env overrides applied 4. Authentication validated 5. Account checked 6. If not initialized → /v1/account/init 7. HTTP SDK starts 8. Storage + blockchain connections active ``` ## 8. HTTP SDK Overview Base: ``` http://localhost:8080/v1 ``` ## 9. SDK Internal Architecture (Critical) S4 is not just API. It internally performs: ``` Wallet Layer → Identity + signing Crypto Layer → Encryption (AES) Fragmentation Engine → Chunking Uploader → Distributed upload Metadata Builder → File mapping Blockchain Signer → Authorization ``` ## 10. Cryptographic Flow (Real Core) ### Upload Pipeline ``` File → Generate fileKey → Encrypt (AES-256-GCM) → Fragment → Upload chunks → Build metadata → Sign metadata → Commit to blockchain ``` ### Download Pipeline ``` txID → Fetch metadata → Verify blockchain → Download fragments → Reassemble → Decrypt ``` *** ## 11. Account APIs ### 11.1 Initialize ``` POST /v1/account/init ``` ``` { "force": false } ``` *** #### Response ``` { "data": { "mnemonics": ["word1", "..."], "raw": "full phrase" } } ``` ### Behavior * Writes mnemonics to `s4.yaml` * Must run once ### 11.2 Restore ``` POST /v1/account/restore ``` Used for: * migration * disaster recovery ## 12. Storage APIs ### 12.1 Upload ``` POST /v1/storage/upload ``` ``` { "files": ["/absolute/path/file.pdf"] } ``` ### What Actually Happens 1. File encrypted locally 2. Split into chunks 3. Distributed across storage 4. Metadata created 5. Metadata signed 6. Transaction written to blockchain ### Response ``` { "data": { "transactions": [ { "id": "tx_abc123" } ] } } ``` ### Important Concept `txID` = your file reference\ Filename is irrelevant ### 12.2 List ``` GET /v1/storage/ ``` ### 12.3 Details ``` GET /v1/storage/{txID} ``` ### 12.4 Download ``` POST /v1/storage/download/{txID} ``` ``` { "path": "/downloads/" } ``` ### 12.5 Delete ``` POST /v1/storage/delete ``` ``` { "tx_id": ["tx_abc123"] } ``` ### Delete Guarantees * Cryptographic erasure * Blockchain record * Irreversible ## 13. Deep SDK Implementation (Developer View) ### 13.1 Encryption ``` const fileKey = randomBytes(32); const encrypted = AES_GCM_encrypt(file, fileKey); ``` ### 13.2 Fragmentation ``` split(file, chunkSize = 5MB); ``` ### 13.3 Metadata ``` { "chunks": [...], "fileKey": "encrypted", "owner": "publicKey" } ``` ### 13.4 Signing ``` signature = sign(hash(metadata), privateKey); ``` *** ## 14. Example: Full SDK Upload (Pseudo) ``` async function upload(file) { const fileKey = genKey(); const encrypted = encrypt(file, fileKey); const chunks = split(encrypted); const uploaded = await Promise.all(chunks.map(uploadChunk)); const metadata = buildMetadata(uploaded, fileKey); const signature = sign(metadata); return sendToS4(metadata, signature); } ``` ## 15. Multi-Cloud Distribution ``` providers = [AWS, GCP, Azure] chunks[i] → providers[i % n] ``` ## 16. Security Model (Deep) ### Zero-Knowledge | Layer | Can read data? | | ------------- | -------------- | | S4 | ❌ | | Storage | ❌ | | TransferChain | ❌ | ### Key Custody * derived from mnemonics * never stored centrally * no recovery possible ## 17. Blockchain Guarantees Each operation: * transaction hash * timestamp * immutable record ## 18. Logging & Observability * JSON structured logs * transaction correlation * SIEM compatible ## 19. Failure & Recovery ### Scenario: Lost Server → Restore via: ``` POST /v1/account/restore ``` ### Scenario: Lost Mnemonic → ❌ Data permanently lost ### Scenario: Storage Compromised → attacker sees only fragments ## 20. Performance Considerations ### Chunk Size | Size | Impact | | ----- | --------------- | | Small | higher security | | Large | faster | Recommended: ``` 1MB – 20MB ``` ### Parallel Upload ``` Promise.all(chunks.map(upload)) ``` ## 21. Compliance Alignment Supports: * GDPR * HIPAA * PCI-DSS * ISO 27001 / 27701 * FIPS ## 22. Real Use Case (Your Example - Refined) A logistics platform stores irsaliye documents: * Files encrypted client-side * Platform owner cannot access contents * Data fragmented across storage * Metadata committed to blockchain * **All actions are authorized and validated via blockchain** Result: * No insider risk * No data tampering * Multi-party trust ## 23. Key Differentiation | Feature | Traditional Storage | S4 | | ---------- | ------------------- | ----------------- | | Encryption | Server-side | Client-side | | Access | Admin-visible | Zero-knowledge | | Integrity | Mutable | Blockchain-backed | | Storage | Centralized | Fragmented | ## 24. Final Summary TransferChain S4 is not S3. It is: * A cryptographic enforcement layer * A key custody system * A blockchain-audited data plane * A zero-knowledge storage SDK If deployed correctly, **no external party including TransferChain can access your data** # Using TransferChain S4 This guide provides step-by-step instructions on how to use the Transferchain S4 for initializing the client, managing your account, interacting with the blockchain, and handling storage. ### Using TransferChain S4 You can run TransferChain S4 as a Docker container. The image is publicly available: ```bash docker pull transferchain/transferchain-s4:latest ``` After pulling the image, run it with required configurations and credentials (see Authentication section below). For Configuration File: # Initialize To start using TransferChain S4, you'll need to run the container with your organization’s access credentials. These credentials will be provided upon request (see Authentication section). ```bash docker run --name transferchain-s4 \ -v ./env/s4.yaml:/etc/transferchain/s4.yaml \ -v ./test/data/transferchain:/var/data/transferchain \ -v ./test/log/transferchain:/var/log/transferchain \ -e LOG_PATH=/var/log/transferchain \ -e PORT=8080 \ -e WITHOUT_LISTEN=true \ -p "8080:8080" \ transferchain/transferchain-s4:latest ``` #### Environment Variables * `API_KEY`: Your private API key. * `API_SECRET`: Secret associated with your account. * `IDENTIFIER` : Identifier provided by TransferChain. * `UUID`: UUID provided by TransferChain. Once initialized, the service is available at `http://localhost:9000`. Please contact for Environment Variables:
# Getting Started # Account Account Initialize & Restore **Init** This request allows you to create your cloud account for the first time or to re-create it by force.\ *Note: If this request is successful, the mnemonics will be written to the config file.* **Endpoint:** /v1/account/init\ **Method:** POST \ Body (Optional): ```json { "force": false // if re-create account use true. } ``` Response: ```json { "data": { "mnemonics": ["your", "account", "mnemonics", ...], "raw": "your account mnemonics ..." } } ``` **Restore** **Endpoint:** /v1/account/restore\ **Method:** POST Body (Optional): ```json { "mnemonics": ["your", "account", "mnemonics", ...], "force": false // if re-restore or use other account account use true } ```
# Storage Manage storage commands to upload, download, and delete files from storage. TransferChain S4 provides a privacy-enhancing wrapper around standard S3 operations. * Create secure buckets ((Note: Buckets are created and managed via TransferChain S4’s S3-compatible interface — not directly on AWS S3 or other providers.) * Upload and retrieve files * List objects * Delete objects All objects are: * Client-side encrypted * Split into multiple fragments * Stored across multiple backends (based on your configuration) * Immutable unless explicitly overwritten ### Upload **Endpoint:** /v1/storage/upload\ **Method:** POST
Body: ```json { "files": ["raw file data", "/home/transferchain/file1.zip"] } ``` Response: ```json { "data": { "transactions": [ { "id": "", "version": 2, "type": "storage", "sender_addr": "", "recipient_addr": "", "data": "", "sign": "", "fee": 0 } ], "storages": [ { "UUID": "", "FileName": "", "Size": 97, "Slots": [ { "base_uuid": "", "uuid": "", "storage_service": "", "storage_code": "", "size": 0, "size_rl": 0, "user_id": 0, "chunk_size": 0 } ], "KeyAES": "", "KeyHMAC": "", "UploadDate": "RFC3339 TIMESTAMP", "Policy": { "ID": "", "Identifier": "", "Owner": "", "SourceIdentifier": "", "TargetIdentifier": "", "OPCode": "storage", "Policy": "owner", "EventType": "create", "CreatedAt": "RFC3339 TIMESTAMP" } } ], "mapped_storages": { "": { "UUID": "", "FileName": "", "Size": 97, "Slots": [ { "base_uuid": "", "uuid": "", "storage_service": "", "storage_code": "", "size": 0, "size_rl": 0, "user_id": 0, "chunk_size": 0 } ], "KeyAES": "", "KeyHMAC": "", "UploadDate": "RFC3339 TIMESTAMP", "Policy": { "ID": "", "Identifier": "", "Owner": "", "SourceIdentifier": "", "TargetIdentifier": "", "OPCode": "storage", "Policy": "owner", "EventType": "create", "CreatedAt": "RFC3339 TIMESTAMP" } } } } } ``` # Transfer Coming Soon. # Blockchain Interact with the Transferchain Blockchain. Every action (upload, download, share, delete) is immutably logged on TransferChain’s blockchain ledger. The blockchain layer ensures: * Tamper-proof audit trails * Cryptographic traceability of access and changes * Zero-trust compatibility To query blockchain logs related to your data, contact our team or use the suite provided with enterprise deployments. # Authentication and Access Credentials API token, API Secret and Identifiers needs to be requested from TransferChain via or please contact your customer success manager to obtain them. # Custom Storage Integration TransferChain S4 custom storage integration technical prerequisites and required inputs ### 1. Supported storage type (requirements) TransferChain S4 integrates only with S3 Object Storage (S3 API compatible) systems. #### Supported examples * AWS S3 * MinIO (on-prem or cloud) * Ceph Object Gateway * Wasabi, Backblaze B2 (S3 mode) * Dell ECS, NetApp StorageGRID, Pure FlashBlade S3 * Any storage platform exposing a standard S3-compatible API #### Not supported (by design) * Block storage (EBS, iSCSI, SAN, LUN, etc.) * File storage (NFS, SMB, CIFS, EFS, Windows shares, etc.) * Local disk paths or mounted filesystem Note:\ TransferChain S4 relies on object storage semantics such as PUT, GET, HEAD, multipart uploads, object keys and bucket level namespace. ### 2. Required client inputs #### 2.1. Storage endpoint The client must provide: * S3 API endpoint\ Generic format:\ https\://\\ \ Examples: * MinIO → * Ceph → * AWS → .amazonaws.com (example only) * Region or region-equivalent identifier\ Some providers require a region value for request signing. If not applicable, it can be left empty. #### 2.2. Bucket detail Provide: * Bucket name * Bucket region / zone (if applicable) * Optional prefix / base path\ Example: transferchain/production/ #### 2.3. Access credentials (required) The client must provide static credentials for the target bucket. * Access Key ID * Secret Access Key Credentials must be scoped using least-privilege permissions to the designated bucket and prefix. #### 2.4. Authentication and connectivity constraints Provide: * Outbound allowlist / egress requirements (if firewall restricted) * Proxy configuration (if applicable): * Proxy URL * Authentication method * TLS interception details and CA chain * DNS requirements #### 2.5. Required permissions Credentials must be scoped to the target bucket and prefix. **Object-level (prefix-scoped)** * PutObject * GetObject * DeleteObject * HeadObject * AbortMultipartUpload ### 3. Storage-side configuration prerequisites (recommended) #### 3.1. TLS / HTTPS * Endpoint must support HTTPS with valid certificates * If TLS interception is used, CA chain must be shared and must not break S3 request signing #### 3.2. Multipart upload support * Storage must support multipart uploads for large objects * Client should confirm provider limits:
* Minimum part size * Maximum part count * Maximum object size
If you need any more assistance please contact
# About TransferChain S4 Documentation **TransferChain S4** (Secure Simple Storage Service) is a Dockerized, S3-compatible secure object storage backend built on TransferChain’s patented privacy and security protocol. It ensures **end-to-end encryption**, **client-side data splitting**, and **blockchain-based audit logging** — providing unmatched confidentiality and compliance for enterprises and developers alike. TransferChain S4 is storage-agnostic and integrates seamlessly with your existing infrastructure while enabling full control over **data residency**, **encryption keys**, and **transfer authorization**. This documentation helps open-source developers get started with S4, explaining how to install, initialize, store and retrieve data, and manage transfer and blockchain components securely. # Core Concepts Understanding Core Concepts At TransferChain, there are concepts which are relatively new to the software development in cloud industry. It is crucial to go over these concepts to understan how TransferChain works. # Understanding TransferChain ### Biggest Threat: Centralization Centralized storage and transmission of unencrypted data could lead to a number of problems for service providers and end users. For example, in a conventional cloud file storage and transfer system, login/logout operations run on centralized servers can make identity information vulnerable and be subject to a single-point-of-failure. A shared and centralized database contains all the information, including metadata and public keys. This could be very risky due to the underlying centralization architecture. File operations also run on a centralized server. All the files are uploaded to the same place where all the keys and meta are stored in the same place. In general, there is no data distribution whatsoever. The system network runs on the company's server. Because the system relies on a centralized server, it is difficult, if not impossible, for the company to make it decentralized because all the file operations and key management are connected to a single authorization point. Many systems are unfortunately protected only by the SSL/TLS protocol, the last 15 years have shown that it is not sufficient to rely only on this protocol. Therefore, these types of authentication protocols need to be strengthened by additional security measures. Hence, a potential cybersecurity attack on these architectures could leak private or commercial data. This is already a known issue for many existing cloud storage systems. ### Who Benefits from TransferChain TransferChain can serve a multitude of real-life use cases and can be a stronger alternative compared to the traditional methods. While we will give examples from different sectors, here are a few use cases that briefly discusses how some of the industry verticals can directly benefit from TransferChain’s features: The primary customer market share of TransferChain consists of large corporations and SMEs that require safe, private, fast, storage and data transfer capabilities (including database storage, historical information archiving, API integrations, etc). Every industry is vulnerable to data breaches, but financial, healthcare and supply-chain industries bear the brunt of the risk because of their potential monetary value. The secondary target customer will be consumers; We are aware that consumers today have become substantially more privacy and security oriented. This is due to the recent breaches of multi-billionaire companies, in which consumers’ data are constantly being leaked. Therefore, TransferChain will be a great fit for today and tomorrow as more consumers follow the increased privacy trend. In addition, as consumers are more diverse with their platform needs, we will make sure that TransferChain is compatible everywhere on Android, iOS, Web, Desktop. In addition, our platform will be user friendly and easy for our customers to use and access. # Cryptography # Authentication & Authorization * A user fills in his/her account email address and the password to the fields. * A seed is generated through encryption of the user password with the key computed by PBKDF2 on the mnemonic words

Auth & Auth

# Encryption Encryption Methodologies in TransferChain ### Hybrid Encryption with AES Algorithm over Zero-Knowledge Architecture Each user is assigned a unique ID. In order to increase privacy, a different TransferChain Address is generated for every new transaction, unless the user dictates otherwise, such as by appropriate user configuration settings in the TransferChain App, to use an existing address. A particular embodiment for address generation is discussed further below. TransferChain App executable GUI process can be run on the client side to provide a connection between the TC Vault and other apps/storage areas on the client's device. The file to be sent is then encrypted with the sender’s private key and the public key for the receiver. After encryption is done, the file is parsed into chunks and sent to the TransferChain for distribution across multiple storage nodes using the same methodology. When the App receives notice that the file has been successfully stored, slot and transaction information is created for each recipient and made available to the recipients. ### Zero-Knowlegde Architecture Maintain complete confidentialtiy between you and your recipient. ### Client-Side Key Management TransferChain does not store or generate any key on the server side, all of the encryption keys are only generated and resided on the client device. ### Encryption at Rest & Encryption in Transit TransferChain applies different modes of AES algorithms for each data operation handling. ### High Level Diagram Following Scheme explains how TransferChain works:
### Technical Overview for Data Transfer and Encryption Diagram
# Elliptic-Curve Use of Elliptic Curve Cryptography at TransferChain ### Choice of an Elliptic Curve The only restriction that the underlying proxy re-encryption scheme cryptosystem imposes on the choice of an elliptic curve is that it should generate a group of prime order, since we need to compute inverses modulo the order of this group. In the underlying setting of the proxy re-encryption scheme, we use the secp256k1 curve since it fulfills this latter requirement and is widely used in the blockchain ecosystem; we are exploring other curve choices that could improve performance. ![](https://3966757443-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FdGeEU8LlQNx720hndGNy%2Fuploads%2FRgH5dOU3YCb3kvcfnRsZ%2Fcurve.jpg?alt=media\&token=add8a243-402a-4d59-9494-47afc9a91fa4) # Address Generation ### Address Generation Namely, the address is the first 20-bytes of the SHA512 hash of the raw 32-byte public key
### Mnemonic Phrase Management (BIP39) TransferChain uses address generation from BIP39 standards. Control your own private key through your unique phrases. This structure prevents unauthorized access to your data and gives your full control # Blockchain TransferChain Blockchain # Decentralization Decentralization on TransferChain Ecosystem ### Decentralization & Distribution Decentralization is the process of distributing decision-making power, and/or responsibility away from a central authority. It can be applied to organizations, governments, or even technology systems, like computer networks as in our case. At TransferChain, we have a robust decentralization plan that will happen in 5-7 years, TransferChain network will reach almost 100 nodes in order to achieve absolute decentralized decision-making. All Nodes will be full nodes and only institutions can run nodes in this permissioned network. Our network design aims to improve the liveness, fairness, correctness, and safety of the network. In order to assess decentralization, we evaluate the subject through four separate layers: Social decentralization represents the diversity of computers, individuals, organizations, etc. that join or are able to join the relevant blockchain network. Monetary decentralization represents the balance of value distribution within blockchain networks in which there is a circulation of economic value, and this economic process bears significance for the functioning of the network. ### Architectural Decentralization is Key Architectural decentralization as the decision for centralization or decentralization should be (and often is) made in line with the objective of the design at the very beginning, it represents the perspective adopted by the blockchain network at a fundamental level on how this matter is handled. Protocol-level decentralization represents the perspective adopted by the blockchain network on the decision-making layer with regard to the mechanism of decision-making, how the rules are determined, implemented, etc. This multi-layered analysis indicates that a large body of evidence is required before we can declare a blockchain network as “decentralized.” # Architecture ### ABCI The TransferChain Blockchain uses an interface called the ABCI to communicate with applications. The ABCI allows the blockchain to pass transactions to the application and receive feedback on whether the transactions were processed successfully. The most important messages of the ABCI are: * **CheckTx:** This message is used to check if a transaction meets a few basic requirements. If the checks are valid, the transaction is added to the mempool and relayed to other nodes. * **DeliverTx:** This message is used to process transactions that have been included in a block. It is during this stage that the state of the blockchain is updated. * **BeginBlock/EndBlock:** These messages are executed at the beginning and end of each block, regardless of whether the block contains transactions. They can be used to trigger automatic execution of logic. Any application built on the TransferChain Blockchain must implement the ABCI interface. However, you do not have to implement the interface yourself, as the TransferChain SDK provides an example implementation. Here is a more detailed explanation of each message: * **CheckTx:** The CheckTx message is used to check if a transaction meets a few basic requirements. These requirements are typically things like ensuring that the transaction has a valid signature and that it does not exceed the maximum gas limit. If the checks are valid, the transaction is added to the mempool and relayed to other nodes. * **DeliverTx:** The DeliverTx message is used to process transactions that have been included in a block. It is during this stage that the state of the blockchain is updated. The application can use this message to update its own state, as well as to perform any other necessary actions. * **BeginBlock/EndBlock:** The BeginBlock and EndBlock messages are executed at the beginning and end of each block, regardless of whether the block contains transactions. They can be used to trigger automatic execution of logic, such as updating statistics or performing maintenance tasks. ### BFT Consensus Mechanism BFT stands for Byzantine Fault Tolerance. It is a type of consensus algorithm that allows a distributed system to reach agreement even if some of the nodes in the system are faulty. The BFT algorithm works by having a set of validators, which are nodes that are responsible for proposing and voting on blocks. Each validator has a voting weight, which is determined by the amount of stake that they have in the network. To propose a block, a validator must first collect a certain number of votes from other validators. This is called a prevote. Once a validator has received enough prevotes, it can then propose a block. Once a block is proposed, all of the validators vote on whether to accept it. To be accepted, a block must receive more than two-thirds of the votes. If a block is not accepted, the process starts over with a new proposal. The BFT algorithm is designed to be Byzantine Fault Tolerant, which means that it can still reach agreement even if some of the validators are faulty. This is achieved by using a variety of techniques, such as double-voting detection and secure communication. Here are the steps in the TransferChain consensus algorithm implemented: 1. A validator is chosen to propose a block. 2. The validator broadcasts the proposal to all of the other validators. 3. The other validators vote on the proposal. 4. If the proposal receives more than two-thirds of the votes, it is committed to the blockchain. 5. If the proposal does not receive enough votes, the process starts over with a new proposal. # gRPC ### gRPC Server The TransferChain SDK uses Protobuf as its main encoding library. This allows developers to use a wide range of Protobuf-based tools, such as gRPC. gRPC is a modern, high-performance RPC framework that has client support in several languages. Each module in the TransferChain SDK exposes a Protobuf Query service that defines state queries. These Query services, along with a transaction service used to broadcast transactions, are hooked up to the gRPC server via a function in the application. Here is a more detailed explanation of each part of the text: * **Protobuf:** Protocol buffers are a language-neutral, extensible mechanism for serializing structured data. They are used in a wide variety of applications, including the TransferChain SDK. * **gRPC:** gRPC is a modern, high-performance RPC framework that uses Protobuf as its underlying serialization format. It is a popular choice for building microservices and distributed applications. * **Query service:** A Query service is a gRPC service that exposes methods for querying the state of the blockchain. * **Transaction service:** A Transaction service is a gRPC service that exposes methods for broadcasting transactions to the blockchain. # Data Distribution Data Distribution at TransferChain ### Understanding Data Distribution Using the application, the user selects the file to store. For security, the file is first encrypted on the user's device before any transmission takes place. Various types of encryption schemes can be used. A private/public key encryption scheme has particular advantages. Using such a scheme, the file is first encrypted with the user’s private key, which is only available on their local device. The encrypted file is stored on the user’s device as a temporary file. In a particular embodiment, encryption is done via AES with SHA512 HMAC method with a random 32-byte key (byte keys can be augmented according to the systems performance on different devices with different computational powers) and the Key is generated from a cryptographically secure random number generator. The user app then splits the file into multiple parts or chunks. In an embodiment, the chunks are each fixed by us to 32 KB in size to simplify encryption and preservation of file integrity. However, different sizes can be used and not all chunks need to be the same size. The last chunk can be padded to bring its size to the set chunk side as required. ### Conventional Techniques are Vulnerable Conventional techniques can be used to indicate the total number and order of chunks for use in file reconstruction. The file is then uploaded to the service in chunks via the network. After each chunk has been successfully uploaded, the file is complete and the temporary file on the user device can be deleted. There is no raw data circulated or stored on the service processor. This is a proxy-like intermediary service area that only processes encrypted parsed data and impossible to identify any data because it is encrypted and parsed in random order. Alternatively, the encrypted file could be transferred to the service server and chunking of the file implemented on the server side. Implementing the function on the client side will reduce the processing requirements of the server, reducing back-end operating costs. Each chunk of the uploaded file gets stored in a storage node; the set of nodes selected for file storage. Each node may be used to store one or more chunks. Various techniques can be used to distribute the file in parts to the multiple storage nodes, and chunk distribution need not be evenly done across the various nodes. In general, distribution is dependent at least on file size, the number of chunks, and the number of nodes. File chunks are allocated, e.g., in a random order, to storage ‘slots’ in the service, and the slotted data is pushed to the data nodes. The service will store details reflecting which chunk is in each slot (such as by reference to a chunk number) and which node and node storage address that slot is associated with. A buffer is used to temporarily store encrypted chunks and other data required for this process. If there is an error with the provider, the service can cancel out that operation and try again, perhaps with a different node. Once the encrypted data is sent to the providers, the buffer will be cleaned. ### Technical Overview of Data Distribution
# Immutability Data Immutability ### User Data Immutability on TransferChain Immutability is the property of a system or object that cannot be changed once it has been created. In the context of blockchain and systems, immutability refers to the inability to alter data that has been recorded on a blockchain or in a system. ### **Immutability on Blockchain** Blockchain technology is designed to be immutable. This means that once a transaction is recorded on a blockchain, it cannot be changed or deleted. This is achieved through a combination of cryptography and distributed consensus mechanisms. * **Cryptography:** Each block in a blockchain is hashed using a cryptographic function. This function generates a unique fingerprint for the block. If any data in the block is changed, the hash will also change. This makes it impossible to tamper with the data without invalidating the block. * **Distributed consensus:** Blockchain networks are decentralized, meaning that they are not controlled by any single entity. Instead, they are maintained by a network of nodes. When a new transaction is added to the blockchain, it must be verified by the majority of nodes. This makes it very difficult for any malicious actor to alter the blockchain. Immutability is one of the key features that makes our system so secure. It ensures that data stored on a blockchain is tamper-proof and auditable. This makes blockchain a valuable tool for a variety of applications, such as supply chain management, financial transactions, and voting. # Data Redundancy ### Data Recovery File redundancy refers to the practice of creating duplicate copies of files or data to ensure their availability and integrity in the event of hardware failures, data corruption, or other unexpected incidents. Redundancy plays a crucial role in data management and storage systems, providing an extra layer of protection against potential data loss. By storing multiple copies of files across different storage devices or servers, organizations can mitigate the risks associated with hardware failures, human errors, or natural disasters. ### Geolocational Redundancy At TransferChain, we prioritize file redundancy as a fundamental aspect of our data management strategy. We understand the importance of safeguarding critical files and ensuring their availability to support uninterrupted business operations. To achieve this, we employ a comprehensive approach that combines cutting-edge technologies. By implementing file redundancy measures such as RAID (Reed Solomon Architecture) technology, we minimize the risk of data loss, corruption, or system downtime. This approach enables us to maintain uninterrupted access to critical files, ensuring seamless business operations and providing peace of mind to our clients and stakeholders. Our commitment to file redundancy reflects our dedication to data integrity and resilience in the face of unforeseen challenges. Geolocational redundancy is crucial for structure. We understand that accurate and reliable location information is vital for our customers, and any disruptions or failures in our services can have significant implications for their operations, customer experience, and overall business success. To ensure the utmost reliability and availability of our geolocation services, we have implemented robust geolocational redundancy mechanisms. # Multi Region Availability Data Residency & Multi Region Availability ### Multi-Region At TransferChain, with multi-region availability for storage services is a crucial feature that we implemented. By complying with data sovereignty regulations and keeping data within specific jurisdictions, we help you meet your compliance requirements. With multi-region availability, we optimize performance by serving data from the region closest to you or your users, minimizing latency and delivering a superior user experience. Trust in our system's robust infrastructure, designed to protect your data and ensure uninterrupted access from anywhere in the world. ### Data Residency Option Enabling compliance for jusrisdiction specific regulations, and additional peace of mind by allowing businesses to choose where to store data # Secure Messaging Coming Soon on SDK This system covers secure messaging protocol and satisfies the following security properties; ### Correctness If no attacker interferes with the transmission, Bob outputs the messages sent by Alice in the correct order and vice versa. ### Immediate decryption and message-loss resilience (MLR) Messages must be decrypted as soon as they arrive. If a message is lost, the parties do not delay and waste time. ### Authenticity While the parties' states are uncompromised (i.e., unknown to the attacker), the attacker cannot change the messages sent by them or inject new ones. Privacy: While the parties' states are uncompromised, an attacker cannot obtain any information about the messages sent. ### Forward secrecy (FS) All messages sent and received prior to a state compromise of either party (or both) remain hidden from an attacker. Post-compromise security (PCS) (aka channel healing): If the attacker remains passive (i.e., does not inject any corrupt messages), the parties recover from a state compromise (assuming each has access to fresh randomness). ### Randomness leakage/failures While the parties' states are uncompromised, all the security properties above except PCS hold even if the attacker completely controls the parties' local randomness. That is, good randomness is only required for PCS. # Overview of TransferChain System Components High Level Diagram of TransferChain System Components ### High Level Overview of System Components
# Integrations TransferChain Custom Integrations # Active Directory Integration Please go to TCMP area to connect you Entra ID. # DLP Integration Coming soon. # Custom Storage Integration TransferChain S4 custom storage integration technical prerequisites and required inputs ### 1. Supported storage type (requirements) TransferChain S4 integrates only with S3 Object Storage (S3 API compatible) systems. #### Supported examples * AWS S3 * MinIO (on-prem or cloud) * Ceph Object Gateway * Wasabi, Backblaze B2 (S3 mode) * Dell ECS, NetApp StorageGRID, Pure FlashBlade S3 * Any storage platform exposing a standard S3-compatible API #### Not supported (by design) * Block storage (EBS, iSCSI, SAN, LUN, etc.) * File storage (NFS, SMB, CIFS, EFS, Windows shares, etc.) * Local disk paths or mounted filesystem Note:\ TransferChain S4 relies on object storage semantics such as PUT, GET, HEAD, multipart uploads, object keys and bucket level namespace. ### 2. Required client inputs #### 2.1. Storage endpoint The client must provide: * S3 API endpoint\ Generic format:\ https\://\\ \ Examples: * MinIO → * Ceph → * AWS → .amazonaws.com (example only) * Region or region-equivalent identifier\ Some providers require a region value for request signing. If not applicable, it can be left empty. #### 2.2. Bucket detail Provide: * Bucket name * Bucket region / zone (if applicable) * Optional prefix / base path\ Example: transferchain/production/ #### 2.3. Access credentials (required) The client must provide static credentials for the target bucket. * Access Key ID * Secret Access Key Credentials must be scoped using least-privilege permissions to the designated bucket and prefix. #### 2.4. Authentication and connectivity constraints Provide: * Outbound allowlist / egress requirements (if firewall restricted) * Proxy configuration (if applicable): * Proxy URL * Authentication method * TLS interception details and CA chain * DNS requirements #### 2.5. Required permissions Credentials must be scoped to the target bucket and prefix. **Object-level (prefix-scoped)** * PutObject * GetObject * DeleteObject * HeadObject * AbortMultipartUpload ### 3. Storage-side configuration prerequisites (recommended) #### 3.1. TLS / HTTPS * Endpoint must support HTTPS with valid certificates * If TLS interception is used, CA chain must be shared and must not break S3 request signing #### 3.2. Multipart upload support * Storage must support multipart uploads for large objects * Client should confirm provider limits:
* Minimum part size * Maximum part count * Maximum object size
If you need any more assistance please contact
# Management & Roles TransferChain Management TransferChain Management Portal and Roles explained here. # TransferChain Management Portal TCMP ### TCMP (TransferChain Management Portal) The Management Portal can only be used by companies and team accounts as a control panel to manage their own users' limits and permissions. The Dashboard and Reports pages within the Management Portal also lets cAdmins to keep track of their team and/or company's usage and statistics information; User Roles in TCMP stated below: * Admin * User * Developer # User Roles User Roles in TransferChain Ecosystem ### Free User Free users are anonymous users. TransferChain does not know any common user information for fUsers; such as the name, email address, credit card info, address etc. Free users are only given limited access to TransferChain platform’s features, these include; 2 GB of storage, transfers up to 1 GB per request, and limited secure messaging. ### Professional User Professional Users are subscription based paid users (monthly or annually). Professional users are given full access to TransferChain’s individual user features, including 1 TB of storage, transfers up to 20 GB per request, and unlimited secure messaging. In addition, all of their files are encrypted, split and distributed to the safest cloud providers in the world, while all of the backend communication is done simultaneously through our blockchain. ### Company Admin Can manage and control their own Company Users through the Management Portal. The permissions include adding and removing team members, managing Groups, and viewing a team’s activity feed. Admins can also choose to require two-step verification for all team members or just specific members. ### Company User 'Company user' role is assigned to the members within a company. These users do not have access to the Admin Panel nor have any admin permissions. Company users can access TransferChain products within the control of the organization's settings. ### Developer User Developer role can reach to the SDK dashboard and get API Secret and keys in order to develop on TransferChain protocol. # Billing & Payment Billing & Payment Information # Developer Plan Developer Role for SDK ### Roles for SDK Development User must be Developer to engage in the SDK. Please go to [Pricing Page](https://transferchain.io/pricing/business) for further details. **Disclaimer:** Please contact support for Developer Account: # Resources TransferChain Resources Please feel free to navigate through our other resources. * Blog * Support Center * Knowledge Base * Community