Futaba is a modular omnichain interface enabling communication between contracts, rollups and blockchain networks by querying and pulling data from a single source chain.

Futaba unifies liquidity, community of users, accounting and management of a dApp or an ecosystem

by enabling data to be pulled from one / many chains to one single source chain

while secured modularly by Konoha, which is made up of multiple validation / security modules that builders can choose to incorporate to optimize their validation method.

If one of the modules are exploited, Futaba is still secured by Konoha and its other unaffected modules.

As Ethereum and other blockchain ecosystems continue to evolve, rollups, Layer 1 and Layer 2 blockchain networks are increasing daily. However, these chains and rollups are mostly isolated from one another. For example, the data of a dApp on Ethereum can only be accessed from within Ethereum - it cannot be accessed from rollups or Layer 2s like Optimism or Arbitrum.

To attempt to solve this, developers deploy a new set of contracts on a Layer 2. However, the data is a new set of data on the Layer 2. Now, they have more work: to manage two sets of data - Ethereum, and Layer 2, instead of just one.

3rd party bridge protocols: Send/push data of asset from 1 chain to another

3rd party messaging protocols: Send/push data of arbitrary message from 1 chain to another

High cost: Pushing data from Ethereum would incur Ethereum gas fees which are a lot higher than gas fees paid on L2s. 3rd party protocols also incur extra cost to reduce the time taken to complete the transaction.

High latency: Pushing data securely from Ethereum takes 15 minutes or more.

Reduced security: Pushing data relies on the security of a single 3rd party protocol. This is a single point of failure, without any alternative or backup method of security. In the event the protocol is exploited/hacked, the transaction along with its funds are affected.

Lower cost: Instead of push, pull mainnet Ethereum data from L2s to incur minimal fees.

Lower latency: Pulling data bypasses the 15+ minutes needed to push data from Ethereum.

Modular security: Developers can pick any modules of security for the oracles used in Futaba architecture, such as zero-knowledge validation, cryptographically secure cross-chain state proofs (Lagrange), third party oracles. This prevents single point of failure by relying a single 3rd party protocol.

Data available AND interoperable: Data unique to each rollup / chain is no longer siloed, no longer just available - it is now interoperable. Users can access it by pulling from 1 single source chain.

Build with us by filling out this form (Discord link within)

Participate in our testnet (backup link: https://testnet.futaba.dev) and discuss with other builders in the Discord.

Follow us on Twitter/X to stay updated.

Futaba is a modular omnichain interface enabling communication between contracts, rollups and blockchain networks by querying and pulling data from a single source chain.

Futaba unifies liquidity, community of users, accounting and management of a dApp or an ecosystem

by enabling data to be pulled from one / many chains to one single source chain

while secured modularly by Konoha, which is made up of multiple validation / security modules that builders can choose to incorporate to optimize their validation method.

If one of the modules are exploited, Futaba is still secured by Konoha and its other unaffected modules.

As Ethereum and other blockchain ecosystems continue to evolve, rollups, Layer 1 and Layer 2 blockchain networks are increasing daily. However, these chains and rollups are mostly isolated from one another. For example, the data of a dApp on Ethereum can only be accessed from within Ethereum - it cannot be accessed from rollups or Layer 2s like Optimism or Arbitrum.

To attempt to solve this, developers deploy a new set of contracts on a Layer 2. However, the data is a new set of data on the Layer 2. Now, they have more work: to manage two sets of data - Ethereum, and Layer 2, instead of just one.

3rd party bridge protocols: Send/push data of asset from 1 chain to another

3rd party messaging protocols: Send/push data of arbitrary message from 1 chain to another

High cost: Pushing data from Ethereum would incur Ethereum gas fees which are a lot higher than gas fees paid on L2s. 3rd party protocols also incur extra cost to reduce the time taken to complete the transaction.

High latency: Pushing data securely from Ethereum takes 15 minutes or more.

Reduced security: Pushing data relies on the security of a single 3rd party protocol. This is a single point of failure, without any alternative or backup method of security. In the event the protocol is exploited/hacked, the transaction along with its funds are affected.

Lower cost: Instead of push, pull mainnet Ethereum data from L2s to incur minimal fees.

Lower latency: Pulling data bypasses the 15+ minutes needed to push data from Ethereum.

Modular security: Developers can pick any modules of security for the oracles used in Futaba architecture, such as zero-knowledge validation, cryptographically secure cross-chain state proofs (Lagrange), third party oracles. This prevents single point of failure by relying a single 3rd party protocol.

Data available AND interoperable: Data unique to each rollup / chain is no longer siloed, no longer just available - it is now interoperable. Users can access it by pulling from 1 single source chain.

Build with us by filling out this form (Discord link within)

Participate in our testnet (backup link: https://testnet.futaba.dev) and discuss with other builders in the Discord.

Follow us on Twitter/X to stay updated.