Spanning Labs sees two major themes when thinking about crossing the chasm between early adopters and the early majority.

First, finding true utility. The industry is consistently experimenting to improve use cases for the technology. Outside of financial applications, the industry is seeing traction in gaming, brand management, community/governance, and creative ownership; yet, the staying power of these applications is currently being tested.

Second, technical barriers are severely degrading the user (and developer) experience. Today, Network ecosystems are completely isolated from one another. To access certain applications, users must connect with multiple exchanges, bridges, and wallets, just to engage with a DeFi protocol, NFT project, or Web3 game. The number of users willing to hop through these steps to participate in the existing ecosystem is dwarfed by the potential total addressable market.

Spanning Labs, along with many other institutions, believes the future will unfold in the following way. First, more and more use cases and utility will be unlocked for users, and projects that correctly integrate blockchain technology will gain success. That’s why we’re investing in this space.

Second, as a result, demand for block space will increase and existing networks will not be able to successfully manage the stress on their networks. Instead of the “Network take all” mentality that exists today, networks will optimize for different features such as decentralization, security, privacy, speed, gas savings, etc. Blockchains are already optimizing today — Bitcoin focuses on pure decentralization, Ethereum targets smart contracts that enable DeFi protocols, Solana prioritizes cheap and fast transactions, Cosmos totes interoperability, Polygon Hermes specializes in privacy computation, and IPSF stores NFT images. As this trend continues, there is a need for these specialized networks to interface with one another. That’s what the Spanning Network seeks to solve.

How do we at Spanning Labs define network interoperability?

Interoperability allows multiple blockchain networks to interchange information and leverage data across them.

Interoperability deployed in the right way will decouple user’s experience from the underlying architecture of the application they are utilizing. 99% of Web2 users today don’t know or care which cloud providers or ISPs are powering their favorite application — it just works. Their experience is delightful and their interactions are seamless. The Web3 user experience needs to offer similar experiences for us to successfully onboard the next billion. In this article, we’ll highlight current problems in the space, why interoperability helps solve them, and some examples of interoperability in action.

The Monochain Ecosystem

Up to this point, the industry has only been constructing monochain ecosystems. By monochain ecosystems, we mean that users, developers, marketplaces, and protocols all are deeply, irrevocably tied to the single chain that they are utilizing.

For developers and decentralized applications, when they choose a specific chain, they are also implicitly choosing the users they can reach, auxiliary ecosystem applications (such as wallet providers, DEXs, etc.), and the underlying technology. As projects grow and their needs change, moving to a new chain is effectively like starting from scratch. If they do decide to introduce another network, they are required to redeploy their entire infrastructure on an alternate chain. This limitation would be similar to a Web2 developer choosing to host their app on AWS to access just Comcast users and copying and pasting a version of their app to GCP to reach others.

Users are struggling to participate in the ecosystem as a whole. If an Ethereum user wants to participate in a DeFi protocol built on an L1 in the Cosmos ecosystem, they are required to open new wallets and bridge over assets. If a new Web3 user wants to own a Solana NFT, they may have to head to a centralized exchange, purchase Solana, open a Solana wallet, then transfer it to their new Solana wallet. Users deserve a convenient end experience that should still be able to gain the benefits of decentralized technology and asset ownership without having to manage multiple accounts, send multiple transactions on different applications, nor pay fees to 3rd parties.

For networks, their almost exclusive focus has been to increase TVL and the number of applications built on their network. The goal has been to “win the game”. But as we’ve seen before, those that focus on trying to be the best at everything, end up doing nothing best. In reality, networks predominantly make revenue from the total transaction volume that exists on their network. They are paid based on the number of transactions that flow through their protocol — not the number of users nor the amount of TVL. In a monochain world, users and TVL are effectively the same as transaction volume. However, TVL doesn’t necessarily optimize for transaction volume and revenue. In a multichain world, transaction volume is much more independent, and optimized for users.

What Interoperability Helps Solve

Interoperability allows each chain to continue focusing on what they do best, developers to make architecture decisions that are best for their new use case, and users to maintain one identity across the blockchain ecosystem. In the same way that Web2 developers use MongoDB for storing user data, Stripe for processing payments, and Amazon S3 for storing images, we believe “Web3” applications will be built in the same way. Depending on the end application, teams may care more about decentralization/security over speed/gas savings or they may care about different focuses based on specific features within their application.

For Developers, instead of them being forced to inherit the scalability approach/market/ecosystem applications of the chain they are building on, they can build their solution to scale to their users’ needs. And depending on the interoperability solution that they end up choosing, just deploying a single contract is enough to reach a larger audience.

Users can say goodbye to the days of experiencing fractured liquidity on the assets that they own and managing multiple wallets. This allows them to access the true benefits of the underlying technology such as decentralization, transparency, and community.

For networks, they are allowed to specialize. It becomes less about the sheer number of “users” and more about how many applications with high volume are using their services to process transactions.

How does the Spanning Network approach interoperability?

The Spanning Network is unwaveringly focused on helping teams reach this interoperable future. We’re building for the teams that want to develop multichain applications on Day 1. Those teams that don’t want the chain they deploy on to limit their end users’ experience.

One of the first use cases that we’re working through with existing partners is access to a much larger audience. Applications deploying a multichain Spanning contract from the beginning of their project get access to users from any network across the entire Spanning Network. A contract can be deployed on Polygon network, while an Ethereum user can log in with their Ethereum wallet, mint the NFT paying Ethereum gas, and ultimately own that NFT on Polygon.

Second, many forward-thinking teams are building applications that utilize a multichain service architecture. For example, if you are a gaming company wanting to develop and deploy user avatars for game access on Ethereum, but want most in-game transactions to be processed on a much cheaper & faster network, Spanning supports your multichain development. Your game avatars can trade on OpenSea and collect royalties in ETH, but in-game transactions can be run for a fraction of the gas cost on alternate networks.

The same rings true for gaming companies wanting to build on their own specific sub or side nets who want seamless access to the parent network or even alternate networks in the blockchain ecosystem. We’ll go into more detail in another upcoming blog post featuring our potential gaming infrastructures.

While the Spanning Network is chain-agnostic, all of us on the Spanning Labs team are chain technology evangelists. As chain specialization becomes more mature, it’s critical that teams are thinking about multichain-first protocol development. The next one billion users will come from applications that streamline users’ experiences and appropriately promote the utility of the underlying blockchain technology. The next 1 billion will come from interoperability.

If this sounds exciting to you, join us at our in-person hackathon in San Francisco during SF Blockchain Week. Sign up here.

Build with Spanning

Website | Docs | Medium | Mirror | Discord | Twitter

Citation

https://members.delphidigital.io/reports/finding-a-home-for-labs

They say bear markets are for building and that’s precisely what the team focused on this past month. Let’s all get our bearings, and jump in. 

We expanded the networks available on our testnet, open-sourced our demo application, increased the robustness of the network, added new testing and monitoring, developed our beta program, and had some candid conversations. Let’s jump into a quick recap and then talk about what’s on deck.

Testnet Expanded to 6 Networks

This month we expanded our testnet to six networks! The testnet now supports deployability of Spanning Contracts on both Rinkeby and Mumbai and three new outbound-only networks — BSC Testnet, Arbitrum, and Ropsten. These new networks allow our partners to develop on the testnets for their eventual mainnet deployment and allow the Spanning team to continue our testing with a more robust testnet.

Open-Sourced the Demo Application

To show just how easy it is to build a dapp with the Spanning Network, the team open-sourced our Demo App along with step-by-step tutorials complete with videos to build your own version. These tutorials walk anyone through deploying their first Spanning Application. We promise it’s so simple, that even non-devs can follow these to deploy spanning contracts (verified and tested in-house).

Tutorials here: Your first token, Your first NFT, & Your First Spanning Web App

Github Link: https://github.com/spanninglabs/app-showcase

Increased Robustness of the Network

Audits, additional node support, and internal tracking, oh my. We focused on adding more robustness to the network. This means more validation and a strong foundation that the network is ready to support our customers.

• Secured an audit partner for our smart contracts — Certik. We are actively in the review stage. Follow our results here

• Added Figment and public RPCs as redundant node providers in addition to Ankr for both listening to and settling transaction requests

• Added an internal system for tracking transactions and submitting auto retries for spurious failures (like dropped network connections)

Network Testing & Monitoring

This month we made the following updates to our network testing & monitoring to help show you how serious we are about our uptime.

• Added a watchdog that cycles through all of our network paths and automatically alerts the team when there is a failure or network slowdown

• Fixed a bug in our metrics reporting that caused our metrics to go silent if there was an Ankr node provider outage

• Setup a developer-specific testing environment for load testing and experimental testing without affecting the production deployment

• Achieved 100% unit test coverage on our Spanning Protocol smart contracts!

Developed our Beta Program

The Mainnet Beta program is now official! We have some sweet deals for these initial beta partners and we’re excited to work with them to expand our network tooling.

Beta Program Goals:

• Onboard early access customers to mainnet with the right support

• Intentionally begin to scale the network

• Build out supporting developer tooling — i.e. how can we make it as easy as possible for developers to integrate their apps with the network

• Strengthen our roadmap through validation

Our program is almost completely filled for phase one (through November), but if you are interested in the next phase reach out to us by filling out this partnership form.

Media Features

And last but not least, we were able to participate in some fun AMAs this month. If you’re interested in hearing directly from our founders about these updates, these links are the perfect listen.

• WhaleCoinTalk AMA

• Heartrate Labs AMA

Alright! What’s next?

Over the next 1–2 months, it’s “build build build”. We have the following projects in our pipeline:

• Beta Program will kick off and bring multiple partners to Spanning Labs Mainnet through the end of this year

• Increase network tooling — including a frontend for testing crosschain transactions and a crosschain explorer to view Spanning Network transactions

• Internal architecture updates — Better load balancing across various nodes and zones, better distribution across various cloud providers and geographic regions, and more transparent transaction status monitoring for the public after the initial request is submitted

• Additional support resources for our developer community — including more videos, tutorials, and demo applications

Follow the Progress & Give us Feedback

Website | Docs | Medium | Mirror | Discord | Twitter

The Spanning Labs team is excited to publicly open the Spanning Network testnet for development. Now, engineers and hackers can build directly on our test Network to deploy multichain applications. Our developer documentation and NPM package are accessible and up to date with the latest network functionality.

With the Spanning Network, developers can seamlessly deploy their applications on the best chain for their use case and access users all across the web — without their users having to take extra steps.

The network unlocks the possibility for multichain dapp infrastructure.

What does this mean? In the same way that Web2 applications today use Stripe for payments, Elasticsearch for search, and MongoDB for user data, we believe future applications will use different blockchains to serve different functions. And the Spanning Network helps to make this a reality.

What included in the Spanning Network testnet?

The testnet displays all current functionality available to developers in our Network. This functionality includes:

• Spanning multichain access to users on three testnets: Rinkeby (Ethereum), Mumbai (Polygon), and Fuji (Avalanche) — with more coming soon!

• Spanning multichain contract deployment on Avalanche — with more coming soon!

• Spanning standards for ERC20, ERC721, ERC1155, Ownable + Access Control contracts

• Common ERC contract extension types for access to additional functionality such as mintable, burnable, pausable, upgradeable, etc.

• Customization to support both local and multichain users — multichain users have their own unique Spanning Address

The Demo App

Within the Spanning Labs Demo App, you can see two core implementations of the Spanning Network — multichain ERC20 contracts and multichain ERC721 contracts. The Demo App highlights:

• Crosschain transfers of tokens and NFTs in less than 5 seconds without 3rd party custody

• Minting assets logged in from any chain available in the network, the JadeNFT project shows ownership from users across all available chains

• Introduction of the Spanning addresses, which enables ownership transfer instead of asset transfer

• Connection to Spanning delegates, the endpoints of the spanning network

The Spanning team is working internally, with our partners, and with our community to build more demo applications that showcase the benefits of the Spanning Network. Additionally, we will be open sourcing our demo app within 2 weeks.

The Security Model

The core of the network security model lies in the fact that Spanning Labs never custodies any assets on behalf of customers or users. There is no “honey pot” of assets maintained by Spanning Labs that would be a vector for attack.

In the Network, the asset always stays on the originating chain, inheriting the security of the chain chosen. On the user’s end, they chose their authentication model out of those available in the network. A more detailed article on our security infrastructure will be shared in the coming weeks.

Developers — we’re here for you!

We’ve built the Network functionality for you. We want to build infrastructure and tooling to make it as easy as possible to deploy, monitor, and maintain multichain applications. By prioritizing this, your entire team (or project/DAO/company) will benefit.

You can access our testnet documentation in the links below. Take a read-through, ask us questions, test, and add your app integration into the Spanning Network testnet.

Developer Documentation: docs.spanning.network

NPM Package Download: https://www.npmjs.com/package/@spanning/contracts

What’s Next?

First and foremost, we’re looking to expand the functionality of the network. This means adding more testnets to the network and adding more deployable networks (Ethereum, etc.) in the coming weeks.

An incentive program for our developer network is being launched within the Spanning Labs Discord. Join now to participate in strengthening the network!

And finally — We’re looking for more partners as we shore up the system towards our mainnet launch. We’re looking for developers to test, give feedback, and pilot us towards what we can do to best support your multichain team.

Interested in partnering with Spanning Labs in the future to make your team or project multichain? Fill out our partnership form here.

Let’s Build!

Website | Docs | Medium | Mirror | Discord | Twitter

Web 3 is a systems engineering problem and it necessitates systems engineers.

From Roboticist to Web3 Engineer

When I first started my Web 3 journey, I was frequently told, “smart contract development is like nothing you’ve ever done before; you get one chance to deploy and if you have any bugs you can lose people their livelihoods.”

This was a huge relief to me.

My last few years working on autonomous vehicles were spent leading the cross-functional team that determined what to do around pedestrians. I worked under the assumption that if there was an oversight or a major bug, someone would lose their life, not just their livelihood.

The solution we built was a very complex system of systems with multiple redundant systems of systems. Every time a robot took off on a mission, it had to be bulletproof.

Testing and validating complex safety-critical software isn’t a new problem. Teams building Web 3 applications can draw on decades of experience from engineers who have built technology like rocket ships, airplanes, robots, and self-driving cars.

In fact, many of the challenges in Web 3 relate directly to the skills and experience I’ve gained working on robotics and systems engineering.

Distributed Compute and Consensus

Systems and robotics engineering are at its core the studies of distributed compute systems. An autonomous vehicle may have 30+ individual compute systems between sensors and redundant computers. Much like a blockchain, an autonomous vehicle’s many computers have to reach consensus on what action to take, have to do so quickly, and have to do so deterministically.

Once you start looking at safety-critical aspects, you see even more overlap with Web 3. While the compute on an autonomous vehicle is centralized, it is far from trusted because of the extremely high bar set for safety. You don’t have to worry about your computer maliciously sending you the wrong braking force to stop at a crosswalk, but you do have to worry about your computer calculating that force wrong because of a cosmic bit flip or sensor miscalibration.

This high safety bar leads to many of the same problems we see with trustless Web 3 protocols today; thus they have many of the same solutions. Byzantine consensus algorithms were used to verify flight computer calculations long before they were used for mining Bitcoin. Proof of history was being used on autonomous vehicles for deterministic resimulation years before Solana was founded.

Building on the Shoulders’ of Giants

From first hand experience, I know systems engineers can jump into the most complex of Web 3 problems and architectures with little to no training. Experience building robust networking infrastructures, autonomous vehicles, rockets, robots, or airplanes is directly applicable to the problems Web 3 faces today.

At Spanning Labs, we are bringing in technology directly from our time building autonomous vehicles. The team’s previous experience in topics like heterogeneous graph theory, feedback controls, temporal logic system design, encoding problems into topology, latent space validation, and resource constrained computing has proven invaluable to building our interoperability solution. In fact, our relayer network (BOS) is based heavily on ROS 2, an open source software designed for decentralized swarm robotics, which is also the basis for most major autonomous vehicle communication systems.

Systems and robotics engineers will help build what comes after Web 2. They are Web 3 engineers. The algorithms they are writing, the mental models they possess, and the ability to design safety-validated systems are all directly applicable to Web 3.

Putting the Puzzle Pieces Together

Web 3 doesn’t fully replace Web 2, just as Web 2 before it didn’t fully replace Web 1; rather each generation is a superset of its predecessors. I’m confident that Web 54 will still consist of many static web pages, centralized applications powered by user data, and decentralized ledgers. Thus, the teams building for Web 3 will need to be supersets as well.

Teams will need Web 2 engineers to ensure apps have seamless user experiences, roboticists to design complex state machines, aerospace engineers to create high assurance testing processes, gaming engineers to set up simulation environments, security engineers to protect secret managers, and infrastructure engineers to architect robust services.

There is a need for everyone in Web 3. For Web 3 to reach its full potential, we need to identify and bring in experts from related industries, like autonomous vehicles.

Spanning Labs is looking to build a community where everyone can bring their expertise to the table. For the same reason a Dapp should use multiple blockchains optimized for specific use cases (like Ethereum for high-value asset storage and Avalanche for cheaper computation), a Dapp should optimize their team as well.

If you are a robotics engineer excited by complex state machine design, come build with us.

If you are a frontend engineer driven by delivering the best user experiences, come build with us.

If you are a Web 3 engineer who is obsessed with security, come build with us.

The Spanning Network will be going live with support for a variety of testnets towards the end of this month. We’ll be releasing more documentation over the coming weeks and we are excited to see what innovative projects you build! Let’s make Web 3 spanning.

Join us!

Website | Docs | Medium | Mirror | Discord | Twitter

Interested in partnering with Spanning Labs in the future to make your team or project multichain? Fill out our partnership form here.

Background

Spanning Labs believes in the multichain future. In order to scale to meet the needs of an expanding Web3 user base, multiple blockchains will be needed to power applications and handle the increase in requests. Teams should be able to choose the right chain for their project without worrying about limiting access to potential users. Conversely, users should be able to create and maintain a single Web3 identity, without multiple wallets and personally bridging assets. 

Spanning Labs’ multichain infrastructure is the pathway to this future.

Who is Spanning Labs?

Drew Beller and Prateek Shah, the two co-founders of Spanning Labs, are no strangers to complex distributed systems. When they analyzed the most consequential and most complex problems in the space, the lack of cross-chain communication stood out. They recognized the technical similarities between their expertise in robotics system design and blockchain. The methodologies they designed and built for safety-critical software at Amazon’s self-driving car division have given them a unique perspective on solving the multichain problems in the industry today. They set out to build a solution, and a team to change how the industry thinks about spanning the current ecosystem — introducing the Spanning Network.

How does the Spanning Network work?

The Spanning Network is built on the concept that users can remain on a single network, while fully owning and managing assets that live on alternate networks.

Base Contracts: The Network supports ‘Spanning’ versions of popular base contracts, such as ERC20, ERC 721, ERC 1155, Ownable + Access Control, and more. With as little as a single word change, teams can update their contracts to a Spanning base class, making their project multichain. With that update alone, teams can also take advantage of common ERC contract extension types to gain even more functionality, like mintable, burnable, pausable, upgradeable, etc.

Custom Functionality: The Spanning Network also supports developers adding custom functions on top of existing base class functionalities. With minor changes, developers can update their functions to support both local and multichain users.

How Our Multichain Model Works: When updating contracts to utilize the Spanning Network, two major changes are occurring. First, the ownership fields in your contract change from storing the legacy address to a multichain capable spanning address. Second, it allows developers to define an address for a local Spanning Delegate contract, the endpoint for the Spanning Network.

Transactions: The Spanning Network also supports a native token ($SPAN) that will be used as part of our transaction model.

The network is expanding every day. Soon the team will be opening access to the Spanning Network testnet. In the meantime, if you have questions or feedback, please reach out to the #developers channel in the Spanning Labs discord.

What are the benefits of this approach?

• Exceptional Security: Unlike other bridging solutions today that hold large pools of assets vulnerable to attacks, Spanning Labs never custodies assets or maintains these pools.

• Access to a Larger Audience: Teams can choose the best chain for their application without limiting access to their potential user base. Users can interact with applications via their local chain, without maintaining multiple wallets or bridging assets.

• Unchanging Asset Functionality: Assets never lose their functionality or utility for both users and development teams. Users always access the benefits provided by their owned asset and projects maintain control over the utility of their assets.

What are some use cases?

• Frictionless multichain payment transfers

• Proof of multichain ownership and multichain airdrops

• Gas fee optimization

• Multichain DAO voting and governance

• And more!

What’s next?

Public demo app built on the Spanning Network & more detailed developer docs coming soon.

Join us!

Website | Docs | Medium | Mirror | Discord | Twitter

Interested in partnering with Spanning Labs in the future to make your team or project multichain? Fill out our partnership form here.