Tesseract receives a W3F grant to build a better dApp/Wallet connector protocol

A better dApp/Wallet connector is one step closer as Tesseract has received a grant from the Web3 Foundation to implement its connector protocol.

In the previous article, we focused on why we need a better dApp/Wallet connector in the first place and overview-level details about how exactly Tesseract solves the problem. TLDR; Tesseract aims to increase blockchain usability by providing a universal and easy dApp to Wallet connector.

In this article, we’d like to be more specific and discuss what the W3F grant consists of, what we have already developed, and how a dApp developer can use it.

While Tesseract aims to be a universal dApp/Wallet connector and to be able to work through various transports (IPC, TCP/IP, etc.) with multiple blockchains, our current goals during the first stages of Tesseract development, for which we received the W3F grant, are the following:

• Implement Tesseract Core — create an implementation of the Tesseract protocol that provides APIs to make new transports and support blockchains.
• Add Support for the Polkadot network.
• Build IPC transports for iOS and Android.
• Create test dApps/Wallets that demonstrate the APIs.

All of this development is being done in Rust and thus can be quickly wrapped with native languages (Swift, Java, etc.) in the future and enables the reuse of the Tesseract Core on any other platform that supports Rust.

Since we have completed and delivered our first milestone (Tesseract Core), we now have a pretty good picture of the APIs (even though they are not set in stone yet and may change before the first stable release) and would like to provide a little sneak peek.

As a dApp/Wallet Connector protocol, tesseract provides two sets of APIs for developers:

• client — the API is to be used by the dApps to connect to the Wallets
• service — the API lets the wallet become Tesseract-compatible

In this article, we want to focus on the client APIs as they would be the ones most frequently used by dApp developers. In real-life scenarios, dApp developers will probably use native language wrappers APIs (JS, Swift, etc.) created on top of Rust. Let’s take an example in the Swift language we are aiming for:

The above code sets up Tesseract with default settings and all the default transports, and it injects Tesseract as a signature provider to a Web3 library of your liking. After this, all the requests for signatures get rerouted through Tesseract to the wallet. That’s all a dApp developer will have to do to start using Tesseract; we do the rest of the magic.

However, these native language APIs will be just thin wrappers on top of Tesseract Core API. Here is an example of how it currently works in Rust. Let’s start with the initialization:

The code above creates an initialized Tesseract connector instance with a single transport. Compared to a native wrapper (where we know what defaults exactly to provide), we need to explicitly provide the transports (TCP/IP, IPC, etc.). To proceed further, we need to get a service instance:

Service is bound to a particular blockchain network and can either be used directly or injected into your favorite blockchain library as a signature provider. To use it as an integrated signature provider, it would look something like this:

We would be offering signature provider bridges for the most widely used libraries, though you can easily make one yourself if we missed your favorite lib. Here is an example of a demo blockchain “signTransaction” call:

The code above is taken from our playground app. For simplicity of the Tesseract Core demo, the demo wallet implementation adds “_signed!” to anything you send for signing; thus, the code above will print “Signed transaction: testTransaction_signed!”. Of course, the actual implementations for real-life networks will all have calls relevant to that particular blockchain.

If you are not very proficient in Rust, you might be confused by the `futures::executor::block_on(signed);` line, which is a blocking resolver for asynchronous entities. We need it here because `signed` is a Future, and thus we need to wait until it gets resolved. In native language wrappers, these will be the analogous asynchronous counterparts (Tasks, Promises, Futures) for ease of use in the asynchronous environment, which is typical for modern-day applications.

If you’d like to learn more about other Tesseract APIs: how to integrate Tesseract into your wallet, create custom transports or add blockchains support, please visit our GitHub: https://github.com/tesseract-one/Tesseract.rs.

In the next stage (which is also the second milestone of the W3F grant), we will start adding actual implementations of transports and blockchains, and the first ones will be:

• IPC transport for iOS and Android
• Polkadot blockchain support

Follow us on Twitter (@tesseract_one) and stay tuned for the following articles!