Links

Super Layer

Layer-0, blockchain-agnostic, data transportation, storage, and computation infrastructure framework.
The backbone of Threely Companion and Threely build is Threely's own infrastructure framework called the Super Layer. The Super Layer (SL) is a Layer-0 infrastructure dedicated to performing these core functions - secure data transportation, storage, computation, and communication of SL data with EVM and non-EVM blockchain networks to serve decentralized functions.
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
In almost all cases, developers will be using the Build Dashboard, APIs, SDKs, or a combination of them to interact with the Super Layer - this endpoint to serve functions is called Threely Link. Threely Link authenticates the developer and manages SDK/API calls with payload sanitization, responses, troubleshooting, prioritization, rate-limiting, throttling, retrying, counting, and more. This serves as the developer's front for communicating with the Super Layer infrastructure.

Threely Networks Layer

Threely Networks Layer (TNL) is the topmost layer in the hierarchy that serves as a decentralized routing, data transportation, and computation layer between Threely Link and other underlying components of the Super Layer. TNL is responsible for communicating data to protocols and subscribing to events taking place in them, such as contract executions. TNL handles the computational logic such as data structure translation, encryption, and decryption, access control, token swaps, cron-job functions, transacting signing functions, etc.

Temporary compute instances and security

TNL can also operate as a temporary or permanent, isolated compute environment akin to trusted execution environments (TEE) to perform functions such as wallet creation, hash functions, and transaction signing while logging in to dApps with Threely Enter. These temporary instances are created to perform function-per-user and are terminated after the function (such as wallet creation) is completed. This ensures that minimal to no computational is done on the client side.

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. This eliminates cross-chain bridges that transport data by generating on-chain transactions via contracts, which also results in low throughput. In cases with unsupported ecosystems, data is transported using bridges, and the fee is paid by 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

Access Data Store

The Access Data Store (ADS) is a decentralized data store responsible for storing the public (NFTs, metadata) and private data (Private keys, messages, transaction history) of users in an encrypted format (see Security). ADS' are sharded onto multiple decentralized storage providers like IPFS and more to ensure that there is no single point of failure.

Security

Threely currently uses four decentralized storage providers to shard user data. All four storage providers have robust security inherently built within their logic. Below is an instance of how Threely secures user data stored by one of our four storage providers - IPFS, using TNL computational encryption, access control, and more.

IPFS

Data transported from the ADS to the IPFS store uses Tweetnacl for both symmetric and asymmetric encryption. 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. These keys are not derived from the contents of the file because this leaks to the network in which files you are storing. 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 the network cannot deduce how big an individual data file is from the data at rest. 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 security in the Threely Networks Layer and temporary instances.

Address Store

A decentralized, public store that serves as the resolving end-point for Threely addresses. Threely addresses, public addresses of their mapped wallets, and their corresponding ADS DID are stored in the Access Store. Address Store also acts as an index for Threely addresses to resolve address translation in sub-millisecond response times. This store is mirrored to the Root Blockchain Directory.

Root Blockchain Directory

A public blockchain directory on Polygon Edge with public Threely addresses and their Address Store DID. The Root Blockchain Directory (RBD) is always mirrored to the Address Store by a Directory-Resolver Consistency Runtime Host (DRCR) running in the TNL to ensure that RBD is the source of truth.

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.