Super Layer

Layer-0, blockchain-agnostic, data transportation, storage, and computation infrastructure framework.

The Threely Super Layer (SL) is a core infrastructure framework that forms the backbone of Threely Companion and Threely Build. It is a Layer-0 infrastructure dedicated to performing a range of core functions, including secure data transportation, storage, computation, and communication with EVM and non-EVM blockchain networks.

Threely provides Web3 developers with a toolset to quickly transform conventional onboarding and user-experience flows in their dApps by abstracting away the unnecessarily complex pieces of technical processes that act as a friction point between dApps and end-users while retaining blockchain technology's best inherent qualities. These low-code solutions, like universal Identities, onboarding, broadcasts, and messaging, are enabled by the SL's data transportation, storage, and computational capabilities.

Super Layer and builder application workflow

Threely Link

The Threely Link serves as a developer-facing interface for communicating with the Super Layer infrastructure. Threely Link can be accessed via the Build Dashboard, APIs, or SDKs and serves as the primary means for developers to interact with the Super Layer.

Threely Link performs an array of functions, including developer authentication, payload sanitization of SDK/API calls, response handling, troubleshooting, request prioritization, rate-limiting, throttling, retries, and request tracking. This provides developers with a secure and efficient way to interact with the rest of the Super Layer.

Threely Networks Layer

The Threely Networks Layer (TNL) is the topmost layer in the hierarchy of the Super Layer infrastructure. TNL acts as a decentralized intermediary layer for routing, transporting data, and executing computation between the Threely Link and other underlying components of the Super Layer infrastructure. The TNL is responsible for interfacing with protocols and subscribing to events occurring within them, such as contract executions.

The TNL is responsible for communicating data to protocols and subscribing to events taking place within them, such as contract executions. Furthermore, the TNL serves as the gatekeeper for all incoming and outgoing communication; It handles a range of computational logic, including data structure translation, encryption and decryption, access control, token swaps, cron-job functions, and transacting signing functions.

Ephemeral Compute Instances and Security

The Threely Networks Layer (TNL) serves as a temporary or permanent functional and secure enclave, much akin to a Trusted Execution Environment (TEEs). This allows the TNL to provision functions such as wallet creation, hash functions, and transaction signing when users log in to dApps with Threely Enter.

These temporary instances are instantiated on a per-function basis. They are terminated post-execution of the specific function (e.g., wallet creation), thus reducing the attack surface by limiting/eliminating client-side computation, enhancing security, and safeguarding user data. The TNL, as a result, plays a vital role in facilitating the secure and efficient utilization of data computation that Threely Enter and other Threely components utilize.

Cross-chain interoperability and communication

Traditional cross-chain protocols require hefty developer resources and technical configuration, often resulting in increased development time and barriers to cross-chain communication capabilities. Threely provides an efficient (zero-fee), trustless, and low-code data transportation experience by abstracting away the technical processes of configuring layers, bridges, and contracts to facilitate a set-and-forget multi-chain data exchange experience for all types of users.

In most cases, Threely transports on-chain data using Threely Networks Layer (TNL) directly to the stream endpoint using Threely Link endpoints on partner dApps and protocols via libp2p, allowing Threely to transport data payloads more efficiently with greater flexibility, gas-free, and faster compared to status quo.

This eliminates cross-chain bridges that transport data by generating on-chain transactions via contracts, execution on rollups, and settlement on mainnet, which also results in low throughput and the overhead of payload language translation. In cases with unsupported ecosystems, data is transported using bridges, and the fee is paid by Threely for the user (gasless for the user).

Unlike other cross-chain protocols, Threely isn't required to be integrated natively by a protocol to facilitate communication. Rather, an autonomous developer building on any blockchain, whether ecosystem or not, can integrate Threely to bring our low-code cross-chain solutions directly to their dApps while Threely manages cross-chain communication efficiently. This opens up a whole new crop of cross-chain applications like dApps that leverage the computation of one blockchain, authorization ramps of another, and tokens, payments, and economics of a third to create a single hybrid application with superior functionalities.

Data transportation using TNL and a bridge

Security

Securing Cross-Blockchain Communication from TNL to Threely Link

Threely Link, a cross-blockchain communication endpoint built on libp2p, utilizes avant cryptographic protocols, Noise, and kadDHT, to provide a secure and decentralized peer-to-peer network. The Noise Protocol is employed to establish secure connections between peers. This protocol provides a secure key exchange, authenticated encryption, and decryption of messages and guarantees forward secrecy between communicating peers.

The kadDHT, a Kademlia-based Distributed Hash Table, is used as the payload storage and retrieval mechanism. Each node in the network is identified by a unique ID, and payload is stored in the network using a key-value pair. The nodes are organized in a tree-like structure, known as a routing table, allowing for efficient and effective data storage and retrieval. kadDHT provides a decentralized and fault-tolerant mechanism for data storage and retrieval, ensuring that the network can withstand the failure of individual Threely Link nodes and ensuring that communication is private and authenticated. With the integration of these cryptographic protocols, Threely Link guarantees secure and efficient data transfer across different blockchain networks.

Access Data Store

The Access Data Store (ADS) is a decentralized, secure, and highly available data store responsible for storing the public (public addresses, cosmetic configurations, NFTs, and other meta data) and private data (private keys, seed phrases, messages, transaction history) of users in an encrypted format. ADS uses sharding and multiple decentralized storage providers like IPFS to ensure there is no single point of failure and high availability of user data. Additionally, it uses encryption techniques to secure the data while it is at rest.

Security

Threely currently employs a sharding strategy to distribute and store user data across decentralized storage providers, effectively eliminating the risk of a single point of failure. These storage providers offer robust inbuilt security mechanisms to protect user data. As an example, when utilizing InterPlanetary File System (IPFS) as one of the storage providers, Threely further enhances the security of the user data stored by implementing additional security measures such as cryptographic encryption and access control within the Threely Networks Layer (TNL).

Decentralized Storage - IPFS

Data transported from the ADS to the IPFS store uses TweetNaCl for both symmetric and asymmetric encryption. It means that the system uses xsalsa20-poly1305 algorithm for encrypting files, Ed25529 for signing data and Curve25519 for exchanging keys. Everything from the data, file, directory names, sizes, and other properties is encrypted or obfuscated.

Files are encrypted symmetrically with a random 256-bit key. This is important because if the key was derived from the contents of the file, it could potentially be guessed or derived (for example, your Threely address) by an attacker, compromising the security of the encryption. Files are split into chunks of up to 5 MiB, and each chunk is independently encrypted and optionally erasure coded.

The link from one chunk of a file to the next is also encrypted so that even if an attacker gains access to an encrypted chunk, they will not be able to determine the original file's size or the order in which the other chunks should be reassembled to reconstruct the original data file. Despite all the encrypted data being publicly pinned on IPFS, no one but the intended recipients can deduce any data or friendship graphs.

Read more on the Threely Networks Layer security and temporary instances and Securing Cross-Blockchain Communication from TNL to Threely Link.

Address Store

The Address Store is an immutable, distributed public repository that functions as the resolution endpoint for Threely addresses. It stores the Threely addresses, the corresponding public addresses of their mapped wallets, and the associated Access Data Store Decentralized Identifiers (DIDs). The Address Store also serves as an index for Threely addresses, enabling sub-millisecond resolution and translation response times. The Address Store is replicated to the Root Blockchain Directory to ensure high availability and fault tolerance.

Root Blockchain Directory

The Root Blockchain Directory (RBD) is a publicly accessible blockchain directory that is deployed on the Polygon Edge and contains the public Threely addresses and their corresponding Address Store DIDs. It serves as an immutable ledger for registering computational instances, including transactions, cryptographic operations, access logs, and other relevant data.

To ensure the integrity and consistency of the data stored on the RBD, an on-chain Directory-Resolver Consistency Runtime Host (DRCR) runs within the Threely Networks Layer (TNL) to constantly mirror the RBD to the Address Store, thereby ensuring that the RBD is the source of truth. This mechanism allows for real-time syncing of data between the RBD and the Address Store, thus ensuring that the data stored on the RBD is up-to-date, accurate, and can be trusted.

Remarks

To learn how the above infrastructure components tie together in a real-world scenario, we recommend reading the functioning of Threely Enter (Onboarding).

Get more support

Tell us about your project, and ask us any technical questions you have.

• To integrate, use our Integration form

• To chat with us, shoot a message on Telegram, Discord or email us at [e-mail]