Entangle has undergone rigorous audits by the industry's top security firms — Halborn, Sentnl, and Astrarizon — ensuring its infrastructure is fortified and secure at the highest standards.

Halborn Audits

Sentnl Audits

Astrarizon Audits

Universal Data Feeds (UDF) is a next-generation, high-performance oracle network delivering hyper-fast, cost-efficient, reliable, and highly secure data feeds across multiple blockchains. UDF is the gateway to a new era of decentralized data, enabling real-time, high-frequency data delivery for DeFi, AI-driven applications, and Real-World Assets (RWAs). Supporting both push and pull models through dedicated marketplace contracts deployed on target chains, UDF ensures trust-minimized, low-latency updates while optimizing costs for decentralized applications.

For a deeper analysis, explore the details in our whitepaper.

How does it work?

UDF is a decentralized platform that connects on-chain and off-chain data to smart contracts, facilitating real-time data delivery from a variety of sources. UDF supports both EVM and non-EVM networks with a standardized delivery format that's designed to offer developers the flexibility to work across blockchains — providing a flexible, secure, and scalable infrastructure for creating data-driven solutions across diverse platforms.

By offering both Push and Pull Oracle delivery models, UDF allows developers to choose the most suitable method for their use cases. The Push model continuously updates data at predetermined intervals, while the Pull model gives applications the ability to retrieve data only when needed, optimizing efficiency and cost. UDF empowers decentralized applications to interact with real-time data, whether it’s for trading, cross-chain communication, or any other data-dependent function.

Additionally, UDF offers an intuitive and easy to use marketplace hub, a fully integrated ecosystem, acting as the entry point for users to access feeds. It provides users an all in one page to search for assets and manage their data feed subscriptions.

Features

Explore

Entangle is a programmable interoperability layer that seamlessly connects all blockchains, data sources, and the real world, unlocking endless possibilities for future-ready decentralized applications. With Entangle, developers can easily launch, scale, and automate dApps, tokens and AI agents to interact across all blockchains without limitations.

Entangle’s toolkit provides developers access to ultra-fast, verifiable and programmable data from any source while enabling secure, trustless verification of complex off-chain software on-chain.

The technology stack serves as the foundational toolkit to build and scale mass-adoption ready applications including: DeFAI, Autonomous AI Agents, GameFAI, Real World Assets (RWA), DeSci and more.

For any inquiries or assistance, feel free to reach out to the Entangle team via the or the community via the channel.

Entangle's Pull Model ensures real-time data availability for user transactions, eliminating dependency on scheduled updates. This approach enhances the precision and reliability of blockchain applications by providing up-to-date information when needed.

When a transaction is initiated, the application requests the latest data directly from Entangle's decentralized sources. The data is retrieved instantly from a snapshot of verified data, and is authenticated within the same transaction. This ensures only accurate, real-time data is used, minimizes costs, and provides a reliable foundation for cross-chain applications.

User Transaction

When a dApp user wants to perform an action (e.g., open a leveraged position, or open a lending/borrowing position), the latest data feed proof is included in the transaction’s calldata. This action uses the PullMarketplace contract with the functions verifyWithFee

UDF provides both push and pull oracle solutions through dedicated marketplace contracts deployed on target chains. These contracts enable seamless data access tailored to different use cases. Pull model is like ordering data on demand; push model is like subscribing to a live feed.

At the core of this system is VerificationLib, a smart contract deployed on target chains to aggregate signed oracle votes into a single, consensus-driven value. It supports multiple data types, including price feeds and high-precision floating-point values, ensuring adaptability across various applications.

Both push and pull marketplace contracts operate alongside VerificationLib, leveraging its validation mechanism to guarantee the integrity and reliability of oracle data.

When to Use Push vs. Pull Models

The Pull Model (On-Demand) fetches data only when required, ensuring it is up-to-date and reducing unnecessary updates. This method optimizes for accuracy and cost efficiency since the data is retrieved in real time based on the application’s needs. It eliminates delays caused by maintaining an on-chain state and is ideal for scenarios requiring real-time precision, such as DeFi trades or event-based actions.

On the other hand, for the Push Model (Continuous), data is delivered periodically, irrespective of immediate need, by maintaining an on-chain state. While it ensures that data is consistently available, this approach can introduce delays and inaccuracies due to the cost and technical limitations of frequently updating the on-chain state. As a result, this model is best suited for DEXs or stablecoin issuers requiring continuous price updates for liquidity pools at fixed intervals or price deviations.

Pricing

UDF’s flexible monetization covers both subscription-based payments for push and pull feeds and a pay-as-you-go (PAYG) model for pull verifications, allowing users to choose plans based on their data needs and cost preferences. Pricing details are implemented via the PullMarketplace and PushMarketplace contracts.

The Push Model delivers regular oracle updates based on configurable price deviations (0.25%, 0.5%, 1%, 2.5%, 5%) or a default heartbeat (every 24 hours). Users deposit funds upfront, and subscription costs are shared among all users. This becomes increasingly cost-effective as more subscribers join the same feed.

The Pull Model lets users fetch oracle data directly within their transactions using either Pay-As-You-Go (PAYG) or monthly subscriptions. PAYG users pay a small fee per data request, ideal for occasional queries, while subscriptions offer unlimited data access at predictable monthly rates. Since data updates occur continuously off-chain, users only pay transaction verification costs, regardless of usage frequency.

Please refer to the UDF for in-depth details on how the prices are calculated.

Pull Model

• PAYG (Pay-As-You-Go): Users pay a small protocol fee per request. This model is best for dApps with sporadic or low-frequency data needs, as costs scale with usage. Learn more about the exact formula we use in our . PAYG is solely programatic and cannot be purchased through the marketplace, learn more .

• Subscription: Users can subscribe to continuous data access for a fixed periodic (e.g. monthly) fee, eliminating the PAYG protocol fee. This model is ideal for applications with consistent data consumption, reducing transaction overhead while ensuring predictable expenses. You can manage your subscriptions through the marketplace.

Push Model

• Fair Pricing Model: The protocol ensures pricing transparency by dynamically estimating costs based on gas prices, assets volatility, and cost sharing mechanisms. Users prepay for updates, there is a minimum deposit covering a few updates, and an estimated suggested deposit to cover for about 7 days of updates for the user to be able evaluate costs. Additionally we advise users to also consider the buffer deposit to cove for gas spikes and volatility.

• Exclusive Access: On-chain price data is restricted to paying users, ensuring that only those contributing to the ecosystem benefit from updates.

• Cost Sharing Mechanism: As more consumers subscribe to a feed, the cost per user decreases, making the model more economical at scale.

Cost Structure Across Multiple Chains

Gas prices vary significantly (e.g., Ethereum vs. an L2) and UDF must adapt. Fees vary based on the target chain’s gas costs; higher fees apply to expensive chains, while cheaper chains benefit from lower costs. Pricing is periodically adjusted to reflect changes in network fees, ensuring sustainable operations across all supported chains.

Speed

The Pull Model ensures that data updates are available in real-time, with minimal delay since users fetch and verify updates themselves, making it particularly useful for time-sensitive applications where immediate data updates are crucial, such as trading platforms or live dashboards.

In contrast, the Push Model, may introduce some latency since data is pushed periodically on-chain, an expensive process. While it is generally fast, it is better suited for applications where real-time updates are not as critical.

Gas Usage

The Pull Model provides excellent scalability for applications requiring frequent updates. It is best suited for scenarios with lower transaction volumes, where the cost impact of update verification remains minimal.

On the other hand, the Push Model scales efficiently across all scenarios by providing much simpler flow for feed value retrieval, saving gas for end-users. It's particularly advantageous for applications with medium-to-high transaction volumes, where gas usage is a significant concern. Push users simply read the latest data from storage without incurring additional gas charges, making this model a more cost-effective solution for handling high transaction volumes.

In this section we will guide you on how to implement the Pull Model using the PAYG method.

In this section we will guide you on how to implement the Push Model.

In this step-by-step guide we'll go over how to manage your subscriptions using the Universal Data Feeds (UDF) . This process is an intuitive and straight forward process, follow the instructions below to get started.

This page is under construction and will be available soon. We're exploring Solana connectivity as a possible addition in a future release. We appreciate your patience and encourage you to follow us on social media to stay updated.

This page is under construction and will be available soon. We're exploring Solana connectivity as a possible addition in a future release. We appreciate your patience and encourage you to follow us on social media to stay updated.

The diagram above illustrates the architecture of Entangle's Universal Data Feeds (UDF), a system designed to ensure secure, efficient, and scalable delivery of verified data across blockchains. At its core, UDF integrates data Aggregation, Attestation, and Updating with a convenient Data Delivery method, supporting diverse use cases while ensuring reliability and accuracy.

Terminology

Core Stages

The process begins with data collection, where the raw data is fetched from reliable, high-quality Data Providers at fixed intervals. This data is encapsulated into a structured format containing key attributes such as the feedKey, value, and timestamp. To ensure the integrity and authenticity of the data, it is signed using ECDSA signatures, effectively securing it from tampering. Once packaged, the signed data is sent as an update transaction to the Oracle Chain, where it undergoes aggregation and attestation (validation).

The Oracle Chain serves as the processing hub, consisting of two key modules. It offloads data collection and processing to L2 auxiliary blockchains, enabling fast, distributed data collection and parallel processing for real-time data feeds. The Aggregation module consolidates inputs from multiple publishers into a coherent dataset. Subsequently, the Attestation module creates on-chain verifiable proofs, certifying the accuracy and reliability of the aggregated data on the target chain.

Users can then use the Update Provider Service which is a service to generate snapshots of data which are maintained on the Oracle Chain for consistency and retrieved via a Delivery Method (i.e., an API) for accessibility. It provides a unified reference point, eliminating the need to interact directly with the Oracle Chain.

On the Target Chain, UDF plays a pivotal role in managing delivered data. It enables decentralized applications to access and utilize verified data directly in their logic. It also facilitates verification of data using the VerificationLib which is the smart contract library that handles validating data on target chains. These measures ensure that all signatures are valid, votes are unique, and the data has met consensus thresholds. For numerical feeds, the verification process aggregates the data into a final state, often using statistical methods like medians to derive a reliable result.

Integration with EIB & L2 Solutions

UDF integrates EIB with L2 solutions for scalability, performance, and cost optimization. This approach allows relaying aggregated data snapshots to each target chain. The L2 network is parallelized and synced with EIB to handle specific tasks (aggregator rollups) and offload mainchain overhead while enabling unlimited horizontal scaling.

EIB's robust consensus mechanism (Tendermint BFT) that finalizes data more rapidly than many L1 networks is leveraged by the L2 solutions as a trusted layer to periodically commit their state. This lets the L2 solutions inherit EIB’s security while achieving greater compute bandwidth and lower costs, enabling near real-time data updates.

Additionally, unlike traditional L2 processes, UIP's internal utility networks bypass full block finalization for messages that do not involve value transfers, relying solely on source network finalization to speed up delivery.

In short, UDF leverages the EIB, a specialized blockchain, for orchestrating:

• Cross-Chain Consensus

• Validator Set & Finality

• Performance & Lower Costs

Role of Transmitters & Decentralized Agent Network

A decentralized network of lightweight transmitter nodes retrieves raw data from various sources and cryptographically signs each update before submission to the oracle chain. These signatures collectively form a Byzantine-tolerant proof, ensuring the integrity and validity of the data. Signatures are merged into a final proof, which is used for validation on external blockchains and off-chain applications.

• Transmitters must stake the native EIB tokens to participate in the network, aligning incentives with honest operation. Staked assets act as a security deposit, misbehavior, downtime, or incorrect data submissions result in slashing penalties. This mechanism prevents Sybil attacks while ensuring that only committed, well-incentivized nodes contribute to UDF’s data integrity.

• Generate signatures on data updates, contributing to a trust-minimized consensus.

• Are monitored and rotated, with penalties for downtime or producing inconsistent signatures.

Finalized Data Snapshot

Once finalized, the data snapshot is posted on the EIB/L2 oracle chain, ensuring accuracy through multiple layers of signed votes. The Finalized Data Snap service continuously synchronizes with the oracle chain, providing real-time oracle data for users and push nodes to retrieve validated oracle data efficiently.

The final snapshot is a cryptographically verifiable object that includes:

• Aggregated Value (e.g., BTC/USD = 100,000)

• Timestamp

• Transmitter Signatures

• Optional Extra Metadata (standard deviation, volume data, etc.)

Summary

UDF supports two primary delivery models, Push and Pull. In the Push Model, updates are actively sent by the Push Publisher (i.e., Push Node) to the target chain, while in the Pull Model, users initiate requests for the latest data snapshots and append verification details to their transactions.

UDF offloads computationally intensive tasks such as aggregation and validation to the Oracle Chain, allowing the system to minimize on-chain costs while ensuring rapid updates. Additionally, a robust verification process guarantees that the data remains tamper-proof throughout its lifecycle, allowing cross-chain deployments without comprising data integrity.

UDF is an essential pillar in infrastructure for modern blockchain ecosystems. It excels in delivering accurate, timely, and secure data to decentralized applications, positioning it as a leading solution for cross-chain data delivery.

This page provides step-by-step instructions on how to delegate tokens to your validators. This is a simple and quick process with our intuitive user interface, see below for more information.

UDF is a modular oracle protocol that allows smart contracts to access both Web2 and Web3 data seamlessly, delivering authenticated, customizable data on-demand. It offers developers the flexibility to choose between push and pull data feeds, optimizing cost-efficiency and performance. UDF standardizes data streaming into a universal format, enabling dApps to easily connect with data sources across any EVM and non-EVM network.

Existing dApps or developers planning to build one requiring an oracle for price data, can integrate our data feeds into your smart contracts. Get started by taking a look at one of our guides.

UTS offers three distinct types of token deployments for manually deployed tokens, each with its own characteristics.

Custom Tokens

• Can be launched by anyone

• Not officially registered on the Entangle platform

• Token and connector contracts can be modified by deployers as needed

• Offer maximum flexibility but may lack official recognition

Factory Tokens

• Deployed through Factory contracts

• In the case of UTS Connectors deployment:

  • Underlying tokens remain owned by third parties

  • Provides a standardized deployment process

Verified Tokens

• Registered and vetted by Entangle

• Official recognition on the Entangle platform

• Increased trust and credibility for token projects

For more detailed information about how to verify your token on Entangle platform please visit or check out the guide.

In this step-by-step guide we'll go over how to check if a subscription to a data feed is still active using the Universal Data Feeds (UDF) hub. This process is an intuitive and straight forward process, follow the instructions below to get started.

In this section we will guide you on how to implement the Pull Model using the Subscription method.

This section will help you to set up the environment and get familiar with few examples using UTS Token and Connector.

In this step-by-step guide we'll go over how to connect your wallet and search for feeds to find the one that you'll need using the Universal Data Feeds (UDF) . This process is an intuitive and straight forward process, follow the instructions below to get started.

Universal Tokens are cross-chain native tokens secured by UIP. The Universal Token Standard (UTS) enables token developers to launch new or expand existing tokens across all major blockchains through a within a few clicks.

UTS revolutionizes cross-chain management, giving developers the power to effortlessly expand their assets across popular chains while keeping full control of their smart contracts — UTS requires no special permissions or rights. Take your token to the next level with UTS, the ultimate tool to seamlessly scale and control, and unlock the infinite possibilities of the interconnected web.

Features

UDF’s oracle contracts provide two distinct interfaces, Pull and Push, designed to deliver flexible data access for dApps. Please refer to the section for implementation details.

The Pull interface enables on-demand verification within user transactions, supporting both Pay-As-You-Go (PAYG) and subscription-based models. The Push interface offers subscribed users seamless access to pre-verified, on-chain data updates.

These interfaces, detailed in the table below, leverage VerificationLib to ensure data integrity and adaptability across diverse use cases.

UTS provides a cost-efficient and transparent fee system for cross-chain transactions, ensuring users pay only for the resources required. Its optimized structure minimizes costs while maintaining reliable and secure token transfers.

Gas Fees

Cross-chain transactions require gas fees on both source and destination networks, covering computational tasks like minting, burning, locking, and unlocking. Gas limits dynamically adjust to real-time network conditions to prevent overpayment.

• Destination Gas Limit (dstGasLimit):

This page is under construction and will be available soon. We're exploring Solana connectivity as a possible addition in a future release. We appreciate your patience and encourage you to follow us on to stay updated.

The UTS Connector is designed to add cross-chain bridging capabilities to your tokens. If you want to add bridging capabilities to an already deployed token, the Connector is the solution. Once deployed, it allows tokens to be locked on one chain and unlocked on another, facilitating the creation or release of UTS tokens. You can use the provided contract as it is or adjust it to suit your needs. To get started, simply deploy the Connector, and you'll be able to bridge tokens seamlessly.

Below are two types of Connectors you can choose from based on your needs:

• Connector with

Bridging an asset is simple process with our streamlined and intuitive interface. This guide will walk you through how to link assets using the Bridge.

Addresses

This page provides step-by-step instructions on how to undelegate tokens from your validators. This is a simple and quick process with our intuitive user interface, see below for more information.

If you want your token to be traded against other assets, you'll need to create a liquidity pool. A liquidity pool is a collection of cryptocurrency tokens locked in a smart contract on a decentralized exchange (DEX). It serves as a reserve, enabling users to exchange tokens directly using the pool's locked tokens without requiring a matching buyer or seller. Alternatively, you can watch the video above for a voiced over walkthrough.

EIB is at the core of Entangle's ecosystem. Built on the Cosmos SDK and powered by the Ethermint framework, this highly customised Layer-1 blockchain is designed to function as a central hub, coordinating cross-chain message processing and transaction validation across networks. It employs Merkle tree structures for efficient and secure data storage and retrieval, ensuring data integrity and optimizing storage for high-volume cross-chain applications.

Explore

As the ultimate Web3 unification layer, Entangle brings together all blockchains, applications, tokens, and data sources into one seamless ecosystem. It’s built to accelerate scalability and fuel mass adoption, empowering developers and users alike to leverage cutting-edge technology that transcends the limitations of fragmented systems.

We invite everyone to join our growing ecosystem and leverage innovative technology that accelerates scalability and adoption. Please fill up the partnership request here:

If you encountered any issues during the integration process, or noticed a bug while integrating contracts, we’re here to help — simply submit a request on . Please provide as many details as possible, including any error messages or unexpected behavior you observed. Our team will assist you in identifying the problem and guiding you through a solution.

The fastest way to start exploring and deploying omnichain tokens is through the UTS portal found via the navigation bar on the Entangle website. Deployment through the UTS portal is referred to as automated deployment.

Automated deployment with UTS is specifically designed to simplify the expansion of existing tokens across multiple blockchains while providing the ability to launch new universal tokens. Using the intuitive UTS interface developers can effortlessly configure token details — such as name, ticker, total supply, decimals, and bridging mechanisms. Once the setup is verified, the system handles all deployment tasks, including creating contracts and allocating the token supply across the chosen chains. The UTS interface is designed to minimize errors and streamline processes.

This section provides information on how to launch new tokens, connect existing tokens, and other functionalities related to the UTS infrastructure using the UTS interface.

Explore

Video Guides

For voiced over guides with full walk throughs you can check out our page.

Developers who require greater control and flexibility can customize their token via smart contracts, a process referred to as manual deployment. It allows direct interaction with the Entangle framework and involves deploying token smart contracts to individual blockchains, requiring developers to define all token parameters, and manage bridging mechanisms programmatically.

While this approach offers more control, it requires a deeper understanding of blockchain infrastructure and additional effort to ensure consistency and security across networks. Manual deployment is ideal for projects requiring customized token behavior and complete flexibility in management.

This section provides information on how to create, deploy new tokens, or connect existing tokens to the UTS infrastructure manually.

The Universal Token Standard is built for seamless deployment, management, and cross-chain interoperability of omnichain tokens. Integrated with the Entangle Bridge protocol, UTS enables efficient, secure cross-chain transactions using a flexible framework of smart contracts and mechanisms like mint-and-burn and lock-and-unlock.

Each token has its own token pool, which simplifies cross-chain transfers by handling the necessary token actions. Token pools act as a secure layer that limits how often tokens can be transferred, adding extra protection. They are set up to either "lock" or "burn" tokens on the source chain and then "unlock" or "mint" them on the destination chain. This results in four possible combinations: Burn and Mint, Lock and Mint, Burn and Unlock, and Lock and Unlock.

Bridging

Token bridging is the process of transferring tokens from one blockchain to another, enabling interoperability and seamless interaction across multiple networks. Since blockchains operate independently and cannot directly communicate with one another, token bridging serves as a mechanism to "move" tokens between them.

UTS simplifies token bridging by integrating with the Entangle Bridge Protocol. This system automates the mint and burn or lock and mint processes, enabling developers to focus on token functionality while ensuring secure and efficient cross-chain transfers. With UTS, bridging is decentralized, trustless, and designed to minimize the complexity typically associated with multi-chain operations. UTS offers two modes, expert mode, and simple mode.

Token Models

When transferring tokens there are several different models users can use to handle tokens on source and destination chains. In this section each type of model is explained.

Burn and Mint

The burn and mint model maintains token supply consistency by burning tokens on the source chain and minting an equivalent amount on the destination chain. This preserves total supply during cross-chain transfers and supports custom tokenomics.

Lock and Mint

In the lock and mint model, tokens are locked on the issuing blockchain, and fully collateralized wrapped tokens are minted on the destination blockchain. These wrapped tokens, with burn-and-mint functionality, enable cross-chain transfers and extended functionality.

Burn and Unlock

The burn and unlock model returns tokens to their issuing blockchain by burning them on the non-issuing source chain and releasing an equivalent amount on the issuing destination chain.

Lock and Unlock

The lock-and-unlock model enables cross-chain transfers for non-upgradable tokens by locking tokens on the source chain and releasing an equivalent amount on the destination chain. This method maintains token integrity and requires careful liquidity management to ensure balance across chains.

The UTS Token is designed to be bridgeable by default. Once you create it, you can immediately begin bridging it across networks. You can use the provided implementation as-is or customize it to suit your needs.

In this section, we’ll provide examples of two types of tokens: a simple token and a token that uses cross-chain messages, allowing you to bridge tokens to multiple addresses in a single transaction.

UDF has an easy to use and intuitive hub for quickly managing all of your data feeds. This section walks you through everything you need to know to start using it. Whether you’re exploring data feeds or managing your existing subscriptions, you’ll find step-by-step guides to help you along the way. We’ve kept things clear and practical so you can focus on building without getting lost in the details.

The Universal Token Standard (UTS) is a framework for deploying and managing omnichain tokens across multiple blockchains. It uses mint-and-burn or lock-and-unlock mechanisms to ensure consistent token supply during cross-chain transfers. Integrated with the Entangle Bridge, UTS supports EVM and non-EVM environments, enabling seamless token management and interoperability across diverse blockchains.

Explore

On chains where token already exists UTS offers a lock-and-unlock bridging mechanism, similar to mint-and-burn but requiring additional liquidity for bridging. This guide will walk you through how to expand existing tokens using UTS.

This section provides information and guides for developers intending to use Entangle's Interoperable Blockchain (EIB). If you have any questions or need assistance, please feel free to use our contact form to connect with an expert on our team.

Validators

Each transaction processed on the network requires thorough validation to ensure compliance with established rules and protocols. Validators are responsible for verifying these transactions, ensuring that all operations are accurately checked, recorded, and aligned with the network’s governing principles.

Staking and Voting Power

Validators use the native token, to participate in securing the network. Validators stake the native token to gain voting power, with greater stakes or delegated tokens enhancing their influence over the network's security and consensus. This staking mechanism ensures that validators have a vested interest in maintaining the network's security.

Security and Monitoring

Validators actively monitor the network for signs of malicious activity. Their vigilance is crucial in preventing attacks, double-spending, or other behaviors that could compromise the blockchain's security.

Rewards and Incentives

Validators are incentivized through rewards, which come from gas fees generated by the transactions they validate. This reward mechanism is designed to acknowledge and compensate validators for their crucial contributions and encouraging active participation.

Slashing and Penalties

Validators are held accountable through a robust slashing mechanism that discourages malicious behavior and ensures network security

1. If a validator signs two conflicting blocks, a percentage of their tokens are slashed.

2. Validators that sign fewer than 50 of the last 100 blocks will have a portion of their staked tokens slashed and be temporarily "jailed" for a set period.

Explore

Creating a new token is a simple process with our streamlined and intuitive interface. This guide will walk you through how to create a new token using UTS. Alternatively, you can watch the video above for a voiced over walkthrough.

Multiple Chains

UTS supports launching to multiples chains. The process is similar to the steps described above, for a full breakdown and walk through you can watch the video below.

Entangle's Push Model delivers continuous, automated updates for critical data, such as prices and asset values, across multiple blockchains. These updates are delivered periodically, making them ideal for scenarios requiring data at set intervals or infrequently, without the need for user requests. This is particularly useful for applications like monitoring dashboards or dApps that display market prices or feed metrics, ensuring optimal performance without user-initiated transactions.

The Push Model transmits verified information across blockchains when specified deviations occur and at set heartbeat intervals. All updates undergo a secure, consensus-driven verification process before being published on-chain, ensuring data accuracy and security.

Scheduled or Triggered Updates

UDF push nodes post the current aggregated feed to a target chain at given price deviations of 0.25%, 0.5%, 1%, 2.5%, or 5% depending on the deviation parameter selected by users, or based on a predefined heartbeat of 24 hours to guarantee sufficient data freshness even when price variations are minimal.

This means users with stricter update frequencies bear a proportionally higher cost, increasing a user's cost share. This ensures that users requiring frequent updates pay more, while those with wider deviation tolerances contribute adequately less, maintaining fairness and economic efficiency.

Single On-Chain Storage

The UDF push oracle contract holds the verified value so that authorized users’ dApps can read it without paying additional verification overhead. This is managed by the PushMarketplace contract, and whitelisted addresses can read via the getFeedPrice function.

Fee Model

Subscribed users can share the cost of running the same feed which guarantees cost efficiency for users. As more consumers subscribe to a feed, the cost per user decreases, making the model more economical at scale. Consider checking out our for indepth details on the cost sharing formula.

UDF charges a small percentage on deposits to the push marketplace contract. The push oracle updates cost is shared across subscribed readers, making it cheaper for the UDF push oracle user base wanting continuous access.

Summary

• Gas Efficiency for Consumers: Price reads are restricted to subscribed users and data updates are shared across multiple users, reducing individual verification costs.

• Cost Efficiency for Consumers: Cost sharing mechanisms amongst subscribed users makes subscriptions cost efficient.

• Slight Delay in Data Freshness: Updates happen periodically (price deviation triggers or time-based heartbeats).

• Best for Continuous Data Access

In this step-by-step guide we'll go over how to subscribe to a data feed using the Universal Data Feeds (UDF) . This process is an intuitive and straight forward process, follow the instructions below to get started.

Fee calculation and gas estimation help you understand the costs involved in cross-chain transactions and deployments. These processes account for things like gas limits, payload size, and currency prices on the source and destination chains to ensure your operations run smoothly. Entangle provides to estimate fees for bridging and deploying tokens, making it easier to plan and execute your transactions.

This page explains the logic for calculating transaction fees and estimating gas costs for cross-chain operations, including base fees, payload costs, and optimization strategies handled off-chain by the backend.

Base Transaction Fee

Adding liquidity to the UTS connector is simple, this guide will explain how it's done.

Entangle supports two type of accounts EVM and Bech32. To navigate with the Bech32 address (with ent prefix) you can interact with the CLI commands outlined below.

Converting Formats

You can convert between the HEX and Bech32 format like so:

Before starting any of the examples, you’ll need to set up your environment. We recommend using the development environment. If you choose to use it, please follow the .

Once your development environment is set up, install the core dependencies using the following commands:

After initializing an empty Hardhat project and installing dependencies, you are ready to write your token or connector. Next, try creating a or a .

Explore

Custom data in data feeds refers to user-defined information that is integrated into a data feed to meet the specific needs of a dApp or smart contract. This enables developers to pull tailored data from both on-chain and off-chain sources, facilitating more accurate and relevant decision-making and operations. With UDF, users can easily expand the data available to their applications by incorporating new data types into the Entangle UDF infrastructure.

When Is Custom Data Needed?

• Integrating New Crypto Assets: Add new cryptocurrency price feeds to ensure decentralized exchanges, lending platforms, or wallets always have the latest market prices.

• Real-World Asset (RWA) Integration: Introduce real-world assets like commodities, real estate, or physical goods into the decentralized ecosystem, enabling their tokenization and trading.

• Proof of Reserves Integration: Add external data feeds to verify asset reserves, providing transparency and confidence in the backing of digital assets or financial platforms.

Requesting New Data Types

To integrate new data into UDF, and provide the following information:

• Initial Data with Examples: Share real sample data that will be processed during the integration.

• Data Processing Requirements: Outline any necessary transformations or formatting for the data to be delivered on-chain.

• Update Frequency Suggestions: Recommend the desired update frequency to tailor the integration to the protocol’s needs.

Integration Process

This section outlines the process of integrating a new data feed into UDF. The default integration flow ensures smooth onboarding of new data sources and utilizes UDF’s capabilities for fetching, parsing, and distributing data on-chain.

The main idea of this connector is to have a possibility to bridge native currency between chains.

Create contract with name UTSConnectorNativeShowcase .

You need to import:

UTSBase is our main contract that should be inherited by any Token or Connector.

In this implementation we also used Ownable

We are starting with defining contract and dependencies. As access control we are choosing Ownable.

Also we need to define NATIVE_TRANSFER_GAS_LIMIT some errors and address converter library.

Then we need do define constructor. Since it is connector, we need _nativeCurrencyDecimals( since our asset for bridging is native currency, we can provide a null address, but meaningful decimals value still required). We need also setup _router address, that can be found .

_allowedChainIds are simply whitelist of chain id's, where you are allowing to bridge tokens.

_chainConfigs is array of settings responsible for bridge settings. We described this config .

In constructor we need to call __UTSBase_init function to initialize UTS Base contract. Also we need to set router and chain config.

_nativeTransferGasLimit serves for defend your and your users gas to avoid attack vector over too complicated or useless receive function at the receiver address.

Lets start with defining 2 view functions that will help us to track balance of this connector and also decimals of native currency and also receive function that will allow our connector to receive native currency.

After this step we need to override 3 functions: _mintTo, _burnFrom and _authorizeCall.

In the outbounding transaction we need to ensure that msg.value we are going to accept is greater than amount, to ensure that we received enough native currency.

In the inbounding transaction we need to ensure that we have enough native currency on connector balance and as a transfer method we will use raw call, since we want also provide restricted gas value.

Don't forget to check success.

Last but not least we need to override one our internal function that is responsible for sending request to router for bridge proposal. Here we need modify value of this message. Main fee asset in our protocol is native currency, and we need to transfer some fee to router to pay fee. If we will leave as it is, it will transfer whole msg.value to router. It is incorrect logic in this case, so we need to substruct our amount that will be locked on the connector balance.

So, our contract is ready, now it can be deployed on networks and we can start bridging tokens between each chain.

Create contract with name UTSConnectorLockUnlockShowcase .

You need to import:

UTSBase is our main contract that should be inherited by any Token or Connector.

In this implementation we also used Ownable, Pausable and IERC20Metadata

We are starting with defining contract and dependencies. As access control we are choosing Ownable.

Then we need do define constructor. Since it is connector, we need underlyingToken_(the token that will be bridged through UTS protocol). We need also setup _router address, that can be found .

_allowedChainIds are simply whitelist of chain id's, where you are allowing to bridge tokens.

_chainConfigs is array of settings responsible for bridge settings. We described this config .

In constructor we need to call __UTSBase_init function to initialize UTS Base contract. Also we need to set router and chain config.

After this step we need to override 3 functions: _mintTo, _burnFrom and _authorizeCall.

So, here is very simple logic, in the outbounding bridge transaction, we need to transfer tokens from spender to connector address, in the inbounding redeem transaction, we need to transfer tokens from connector to receiver to address.

Also we will implement one more function: getter for underlying token decimals.

Also we need to use SafeERC20 library by OpenZeppelin.

So, our contract is ready, now it can be deployed on networks and we can start bridging tokens between each chain.

Create contract with name UTSConnectorMintBurnShowcase .

You need to import:

UTSBase is our main contract that should be inherited by any Token or Connector.

In this implementation we also used Ownable, Pausable and IERC20Metadata

We are starting with defining contract and dependencies. As access control we are choosing Ownable and we also want make this contract as Pausable, because in bridge flow it is also nice to have an option to pause all interactions to make some changes for example.

Then we need do define constructor. Since it is connector, we need underlyingToken_(the token that will be bridged through UTS protocol). We need also setup _router address, that can be found .

_allowedChainIds are simply whitelist of chain id's, where you are allowing to bridge tokens.

_chainConfigs is array of settings responsible for bridge settings. We described this config .

In constructor we need to call __UTSBase_init function to initialize UTS Base contract. Also we need to set router and chain config.

After this step we need to override 3 functions: _mintTo, _burnFrom and _authorizeCall. We need to do it, because this connector is mint/burn, so, internal logic should be of main bridging function should be done via mint/burn of underlying token.

So, here is very simple logic, in the inbounding redeem transaction, we need to mint tokens, in the outbounding bridge transaction, we need burn tokens.

Also we will implement 3 more functions to controll pause state and getter for underlying token decimals.

Also we need extended ERC20 interface to call mint and burn functions. In this example, we use standard mint and burnFrom token functions, but you can use any interface and logic supported by your underlyingToken contract.

So, our contract is ready, now it can be deployed on networks and we can start bridging tokens between each chain.

Token verification is an optional process that enhances the visibility and usability of your token in Entangle’s bridge and dApp ecosystem. By verifying your token, it becomes searchable by name rather than by address, improving user accessibility and integration within the platform.

After deploying your token and setting up its cluster, you can use the bridge and associated dApps. By default, users can search for your token using its contract address. Token verification ensures your token is indexed, allowing users to find it quickly by name in search fields.

After deploying and setting up your cluster you can start bridging and using our dApp for this purpose, but by default, you can find your token using address only. This guide will help you to verify your token and after verification, we will index your token and you will have a possibility just to write the name of your token in the search field.

Verification Steps

Notes

Create contract with name UTSTokenShowcase .

You need to import:

import "@openzeppelin/contracts/access/Ownable.sol";
import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@entangle-labs/uts-contracts/contracts/ERC20/UTSBase";

We are starting with defining contract and dependencies. As access control we are choosing Ownable and also since it is UTS Token we need to import ERC20 implementation, here we are using one by OpenZeppelin.

UTSBase is our main contract that should be inherited by any Token or Connector.

In this implementation we also used Ownable and ERC20

Then we need do define constructor. Since it is Token, we don't need a lot, just general UTS settings and ERC20 metadata.

We need setup _router address, that can be found .

_allowedChainIds are simply whitelist of chain id's, where you are allowing to bridge tokens.

_chainConfigs is array of settings responsible for bridge settings. We described this config .

In constructor we need to call __UTSBase_init function to initialize UTS Base contract. Also we need to set router and chain config.

After this step we need to override 3 functions: _mintTo, _burnFrom and _authorizeCall.

So, here is very simple logic, in the outbounding bridge transaction, we need to burn tokens from from address (do not forget about ERC20 allowance check), in the inbounding redeem transaction, we need to mint tokens to receiver to address.

So, our contract is ready, now it can be deployed on networks and we can start bridging tokens between each chain.

You can extend the base implementation of the UTS Token or UTS Connector to meet your specific requirements. To implement your custom token, you’ll need to follow a few basic guidelines.

We offer several functions to help you estimate costs, including bridging and deployment fees.

Bridge Costs

To estimate bridge fees and minimum gas limits, we provide the estimateBridgeFee function. See below for more information.

Users can renew their previously subscribed data feeds without the need to set the parameters again. In this step-by-step guide we'll go over how to renew your subscriptions using the Universal Data Feeds (UDF) . This process is an intuitive and straight forward process, follow the instructions below to get started.

Users can renew their inactive subscriptions from the "" section or from the "" section of the dashboard.

Notification Section

This provides everything you need to integrate the Web3 Bridge into your frontend application. The bridge supports multiple chains and tokens, offering seamless interoperability for Universal Token Standard (UTS).

Setup

After cloning the

The Entangle Interoperable Blockchain consists of 3 Layers:

• Application Layer

• Modules Layer

• Tendermint Consensus Layer

Becoming a validator on the EIB involves setting up your node, creating a wallet, configuring your system, and finally launching your validator node. This guide will walk you through these steps in detail to help you get started.

Hardware Prerequisites

Before proceeding, ensure that your hardware meets the recommended specifications to run a validator node efficiently.

Software Prerequisites

Before you begin, make sure your system has the following software installed:

• Git

• Golang (minimum version 1.21)

• Make

• jq

Step 1: Setting Up Your Node

1. Clone the Entangle Blockchain Repository: Start by cloning the and navigating into the project directory:

2. Build the Project: Compile the project using the make command, which will build the necessary binaries:

   After installation, you can verify the installation by running:

3. Initialize Your Node: Create your node by initializing it with a unique moniker and specifying the chain ID:

Step 2: Wallet Generation

1. Create a New Key: Generate a new key for your wallet. You'll need to provide a key name and select the keyring backend and algorithm:

2. Retrieve Your Address: Extract your wallet address and store for later use:

Step 3: Configuration

1. Update Configuration Files: Download and . You'll need to replace the existing files in your .entangle/config/ directory with these.

2. Set Persistent Peers: In your .entangle/config/config.toml file, update the field with the provided list of nodes:

Step 4: Launching Your Node

1. Start Your Node: With the configurations set, you can start your node. Ensure to specify the chain ID and set the gas cap for JSON-RPC:

2. Verify Node Synchronization: Check if your node is fully synced with the network:

   A response of false indicates successful synchronization.

Step 5: Creating Your Validator Node

1. Ensure You Have NTGL Tokens: To create a validator, you must have a sufficient amount of NTGL tokens for staking and transaction fees.

2. Create Validator: Use the following command to create your validator. Replace <key_name> with your key name and adjust other parameters as necessary:

3. Verify Your Validator Node: Check if your validator has been successfully added to the validator set:

By following these steps, you can set up and launch a validator node on the Entangle blockchain. Remember to keep your node online and perform regular maintenance to ensure its smooth operation and contribution to the network's security and efficiency.

Create contract with name UTSTokenWithLogicShowcase .

You need to import:

We start with defining the contract and the dependencies. For the access control we choose Ownable and also since it is UTS Token we need to import ERC20 implementation, here we are using one by openzeppelin.

UTSBase is our main contract that should be inherited by any Token or Connector.

In this implementation we also used Ownable and ERC20.

Then we need do define constructor. Since it is Token, we don't need a lot, just general UTS settings and ERC20 metadata.

We need setup _router

Using the Push model means retrieving data from on-chain contract storage. This requires the data to exist in the on-chain contract storage, uploaded by a publisher or node operator beforehand. UDF maintains a node that continuously publishes updates for supported assets, but anyone is free to run their own node instance to ensure redundancy or customize their setup.

To utilize an update in your contract, you can read the value of the asset of interest from the PushMarketplace contract deployed on each supported chain. For demonstration purposes, in this guide we will create a consumer contract whose logic depends on the BTC/USD price.

Step 1: Initialize hardhat project

First of all, let's create new project and initialize hardhat in it.

Step 2: Create PushReader contract and hardhat ignition script

Next, let's create our consumer contract. The consumer contract, referred to as the PushReader, will retrieve data stored in PushMarketplace, which assumes the availability of verified updates pushed on-chain beforehand.

In this example, the contract will read the latest stored price of the BTC/USD asset and store it. To achieve this, we'll use the getFeedPrice function, a free data retrieval method for previously subscribed readers.

This contract should already be in subscription so it can have access for verification. The subscription can be purchased from the marketplace and the consumer contract needs to be added as an authorized address for the subscription.

For convenience, this function returns both the price and the timestamp in a single call. Providing both values ensures that users can verify the freshness of the data, which is critical for applications where price accuracy and timing are essential for decision-making.

Next, create an ignition script to help with deployment of the new PushReader contract.

Step 3: Deploy PushReader

Now let's modify the hardhat configuration file to add the eth_sepolia network.

Now we can deploy the PushReader contract by running the command below.

Step 4: Create Push Subscribtion

Now we should add deployed PushConsumer(PushReader) contract as allowed address to our subscribtion.

for desired feed and with desired parameters and put deployed PushConsumer contract as address that can read the contract.

Step 5: Execute PushConsumer.consumePrice transaction

To validate that we have our price, we will write an example backend script that send transaction to execute PushConsumer.consumePrice.

Let's create a separate directory called "scripts" and create a new script consumePrice.ts in it.

Change the PushReaderAddress to the address you got from deployment and execute the script to send the transaction to the blockchain.

You can use cast to examine the transaction call trace and logs. The emitted event shows the latest update that we read. Note that gas usage may vary depending on the result and the version of the library in use.

We are pleased to share Entangle’s media kit, which contains essential brand assets, key messaging, and valuable resources to support our shared efforts. As we continue to drive innovation in Web3, this kit will provide you with everything needed to accurately represent Entangle and strengthen our partnership. Together, we are building the future of decentralized technology.

Guidelines

• Do not crop the logo, rotate it, or place it with other colors

• Do not re-create using any other typeface

• Do not use shadows, transparency, or any other effects

• Refrain from altering the shape, and proportion of the logos

• Keep padding around the logo.

Colour Codes

Logos

Backgrounds

​