DEV Community: Bianca Buzea

Choosing the Right Oracle Solution: A Six-Dimensional Framework

Bianca Buzea — Sat, 08 Mar 2025 19:28:51 +0000

Most DeFi builders put a lot of effort into choosing the right chain, finding the best way to attract liquidity, and ensuring their protocol is optimized for performance. Yet, many overlook the importance of selecting the right oracle solution. As long as the price feeds are returning a value, it’s easy to overlook the crucial role oracles play in the system.

Then the unexpected strikes. The oracle suddenly feeds an incorrect price for a key asset. Automated trades fire off at distorted values, collateral is miscalculated, and positions are liquidated unexpectedly across lending platforms. A cascade of liquidations and bad trades ripples through the DeFi ecosystem. In a matter of minutes, the oracle—once taken for granted—becomes the center of attention as protocols and users scramble to contain the fallout.
The fallout is immediate and painful. Users lose funds, developers are stuck in damage control, and the trust that DeFi protocols rely on takes a hit. The root of the issue? Relying on a centralized oracle—a single point of failure in an otherwise decentralized system. Suddenly, everyone is questioning the reliability of the data driving DeFi, and the vulnerability becomes impossible to ignore.
Decentralized oracles step in to restore order. Instead of trusting one source or relying on a bridge for delivery, decentralized oracles integrate natively, aggregate price data from multiple sources, and verify it through a network of validators, reducing the chance of manipulation or failure. DeFi protocols start adopting decentralized oracles to ensure price accuracy and reliability, preventing future catastrophes. It’s a necessary upgrade in the pursuit of trustless finance.
With decentralized oracles in place, DeFi is in a stronger position. Now, the chances of a single bad point of failure causing massive liquidations or flash crashes are dramatically reduced. The data feeding into your protocol is more secure, more reliable, and more decentralized—just like the DeFi ecosystem itself. You may not have cared before, but now, decentralized oracles are the backbone that keeps your protocol running smoothly and your users protected.

Oracle decentralization is an essential element, but there is much more to consider when choosing an oracle. In this article, we will present you with a framework that you can use when choosing an oracle to power your application, this framework considers 6 important dimensions:

The Oracle's Operational History
Total Value Secured (TVS)
Decentralization
Node Operators/ Validators
Data Sources Utilized
Operating Cost

The Oracle's Operational History

When selecting a Web3 oracle for your DeFi protocol, evaluating how long the oracle has been securing assets is crucial. Oracles that have operated successfully over time demonstrate resilience and reliability, two essential qualities for securing funds in DeFi. A proven track record shows that the oracle can handle market fluctuations and scalability demands. Ultimately, opting for a well-established oracle helps safeguard your protocol by relying on an experienced data provider with a history of maintaining uptime and accuracy.

Total Value Secured (TVS)

Total Value Secured or TVS is also a key metric to consider when choosing an oracle. TVS indicates the amount of value reliant on the oracle's data, reflecting trust from other protocols and the market's confidence in its reliability. A high TVS demonstrates that the oracle has successfully secured a large amount of assets without security issues, which can be reassuring for new users aiming to protect funds. By choosing an oracle with substantial TVS, you’re aligning with a provider that has proven its ability to secure high-value assets, reducing the risk to your own protocol’s users.

Decentralization

Decentralization is essential for Web3 oracles because it aligns with the core philosophy of Web3—trustlessness, transparency, and resilience. While blockchain networks offer strong guarantees of consistency and availability within their ecosystem, the external data sources they rely on do not. APIs, databases, and external websites can be hacked, altered, or even go offline, creating potential vulnerabilities. By using a decentralized network of validators, a Web3 oracle can minimize these risks, ensuring that no single point of failure or manipulation compromises data integrity or availability. Decentralized oracles distribute responsibility across multiple nodes and tap into diverse data sources, making the oracle more robust and secure—a crucial safeguard for protecting funds and maintaining trust in DeFi and other decentralized applications.

Node Operators/ Validators

The validator network is at the heart of a Web3 oracle's decentralization and security. A critical question to ask when evaluating an oracle is: Who operates the nodes? If the oracle solely relies on nodes operated by its team, there is an inherent risk, even if the intentions are sound. Relying exclusively on internal nodes introduces a single point of failure and reduces resilience, as any technical failure, malicious attack, or simple human error could disrupt the service.

In contrast, a decentralized validator network consisting of independent, reputable entities promises high levels of data integrity and network security. With multiple validators, no single entity can compromise or influence the data delivered to smart contracts, reducing the chance of manipulation or error. Validators from varied geographical locations and operating different infrastructure setups add resilience, distributing risk across a diversified network.

Data Sources Utilized

When evaluating oracle networks, it’s essential to scrutinize the quality and integrity of their data sources. Key questions include: What sources does the oracle network rely on? Does it leverage tier-one, reputable data sources with established credibility, high liquidity, and a proven track record? Does it use primary sources, or secondary sources such as data aggregators? For oracle networks using onchain data sources, such as DEXs, are there at least 2-3 reliable data sources—ideally with at least two on the same chain—to enable MEV bots to arbitrage and prevent market manipulation?
High-quality data sources are fundamental to minimizing the risk of inaccuracies or exploitation. Oracle networks must prioritize Tier 1 data sources with healthy liquidity that are resistant to manipulation. In contrast, reliance on low-quality or low-liquidity sources can be prone to market manipulation, undermining the security of the system.

Operating Cost

Lastly, cost is a critical factor when evaluating oracles. By design, oracles are gas-intensive, and during periods of network congestion, fluctuating gas prices can make them prohibitively expensive to operate.
On Ethereum, the annual cost of running an oracle network can exceed $500,000, making high-quality oracles a luxury accessible only to the wealthiest protocols. Even on a Layer 2, the operating cost can be very expensive when you are updating many data feeds, multiple times per day.
One way to reduce costs is by lowering the frequency of oracle updates, but this comes at the expense of accuracy. While it may provide short-term relief, sacrificing data freshness for cost is a short-sighted approach that fails to scale.
An effective oracle solution should strike a balance, employing mechanisms that reduce costs without compromising data freshness. Reliable and cost-efficient oracles ensure both performance and accessibility at scale.

Final Thoughts

As DeFi continues to mature, the importance of carefully selecting an oracle cannot be overstated. An oracle might seem like just another tool, but it holds the power to make or break your protocol. This six-dimensional framework offers a comprehensive approach to making informed decisions when assessing an oracle solution.
By treating your oracle provider as a core component rather than an afterthought, you lay the groundwork for robust, scalable, and secure operations that can withstand the test of time and market volatility.

BuildUP #2 Hackathon Checklist Guide

Bianca Buzea — Thu, 23 Nov 2023 13:36:55 +0000

Hi, it’s Bianca Buzea, Head of Developer Relations at LUKSO. If you are looking to buidl during BuildUP #2, LUKSO’s signature hackathon, then this guide is for you.

I love hackathons. I have attended multiple hackathons as an attendee, judge, and organizer. I strongly believe that when it comes to the success of a hackathon, a significant part can be attributed to having the right tools and keeping yourself organized. That is why I created this guide for you, to give you a head start on BuildUP #2.

Here is what this guide covers:

Over €250K in LYX Bounties
Curious Nuggets
Getting Help
Tips for a successful hackathon
The Power of a Good Presentation
Next Steps

Bounties Overview

Over €250K in LYX Bounties distributed equally across four categories:

⚒️Infrastructure & Tools
🎙️Culture & Entertainment
🧑‍🤝‍🧑 Social & Community
💙 Blue Sky

Requirements:

An URL to your deployed project that judges can test
A short video that describes the scope and functionality of your project (around 3 minutes)
A public GitHub repository with the project’s code

Curious Nuggets:

LUKSO is an L1 chain, EVM-compatible for Creative Economies
Dapps will be judged on their potential as a valuable contribution to the ecosystem, technical excellence, originality and creativity, and user experience and design
Universal Profiles just launched on Mainnet
Bonus points for leveraging LUKSO Standard Proposals (LSPs)’ capabilities, Universal Profiles, and different tools such as (ERC725.js for encoding, or lsp-factory.js for deployments)

Getting Help

Participants got weekly “Q&A with the LUKSO Tech Team” for the duration of the hackathon and a dedicated #hacker-discussion channel in the ⎡HACKATHON⎦ section of the LUKSO Discord server.

Tips for a Successful Hackathon

Don`t reinvent the wheel

Make use of the available tools. There is no need to reinvent the wheel. Besides the generic EVM tools, make sure to check out the LUKSO-specific tools such as ERC725 Inspect, which allows you to inspect the key/values of an ERC725Y compatible smart contract, lsp-factory.js for easy deployments of ERC725-UniversalProfiles, and digital assets, or erc725.js that allows you to interact with ERC-725 schemas easily. You can find a full overview of all the available tools in the Tools section from the documentation.

Focus on the MVP

Aim to build a minimum viable product that addresses the core functionality or solves the main problem. You won’t be able to sort out every single detail and fix every bug. You can always add more features if time allows.

The Power of a Good Presentation

One of the most frequent mistakes teams make during hackathons is to focus exclusively on the code and not allocate time for the presentation. While the code is indeed a crucial part, teams should also make sure to save enough time for the presentation. A captivating presentation is a valuable complement to a technically proficient project. Not only does it describe the scope and functionality, and it captures the judges' attention, but it also helps distinguish your project from others.

Next Steps

Remember that hackathons are not just about bounties; they're also about learning, discovering new technologies, making new friends, and having fun! Enjoy the experience and the opportunity to work on something new and exciting. Also, don’t underestimate where a project might take you. Having a well-built hackathon project serves as a valuable addition to your portfolio and can also serve as a solid foundation for launching your next web3 startup. You never know how far you might get unless you try.

Come check out the LUKSO docs and make sure to submit your project before the 27th of November, 16:00 UTC.

From Beginner to dApp Developer: Learn Solidity and Build a Decentralized Media App

Bianca Buzea — Tue, 30 May 2023 18:25:08 +0000

In this post we will build our first decentralized social media app. We will call it EthSocial, but feel free to be more creative with the naming.
While building the dApp, we will learn about onchain storage, smart contracts, Solidity data types, and decentralized social media.

Our dApp will have the following capabilities:

create an account
make a post (with title and body)
read posts
check users

Before we jump into the actual building, let's first look at the WHY. Why decentralized social media? There are various advantages that decentralized social media offers. Here are some of the most important ones.

Portability: content is no longer controlled by a centralized server or company, it is accessible to everyone, everywhere. Pretend you are a creator on Twitter. You grew a follower base of over 1.5M people. However, recently you decided to expand to TikTok. With web2, you would need to grow your followers base from scratch. However, with web3, you no longer lose your followers, you can port them over to a different dApp.

Users own their data: no more centralized databases. Users own their data and are able to monetize their data how they like. No more Cambridge Analytica incidents because the platform no longer owns user data.

Censorship resistance: Creators can now be relieved from concerns about losing their content or audience due to the unpredictable actions of an individual platform's algorithms and policies.

Now that we had a look at the value of decentralized social media, let's start building.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.17;

First, we define the SPDX-Licence -Identifier. This is important because it specifies under which license other people can use our code. In this example, we will use the open source "MIT" license.

The pragma is used to enable certain compiler features or checks. It comes annotated with a version, this allows use to get specific and ensure our byte code is reproducible even as the compiler changes.

contract EthSocial {
   struct UserStruct {
       string username;
       uint8 age;
       bool isUser;
   }
}

Next, we will create our smart contract. First, we need to define a user with some properties. To do so, we will use a struct. Structs are a data type that offer a way to define new custom types in Solidity that group together related data.
We will name our struct UserStruct, and it will contain three fields, a username of type string, the age of the user of type uint, and a bool, isUser, to keep track if the user is registered with our app or not.

In a similar fashion, we will define a struct for posts, we will call it Post. This time, it will have the following attributes: a title of type string, a body of type string, and a time attribute of type uint.

struct Post {
       string title;
       string body;
       uint time;
}

Now that we have defined our posts, it is time to keep track of who creates a post. To achieve this, we will use a mapping. Mappings in Solidity act like a hashmap or a dictionary in other programming languages. They are used to store data as a key-value pair. We will call our mapping posts, and it will keep track of what address has created each post. Similarly, we will also have a users mapping, to keep track of how addresses relate to user "accounts". In addition, we will also create a counter, userCount, to keep track of the total number of users that have signed up!

 mapping (address => Post[]) posts;
 mapping (address => UserStruct) users;
 uint256 userCount;

Now, it's time that we define a signup function. Our function, createUser will set the value for a user's info.
First we define an instance of type UserStruct, called user. Then, we will set the properties of user using the dot notation. Before returning true, indicating that a user was created, we increase the userCount.

  function createUser(address _userAddress, string memory _username, uint8 _age) public returns (bool success){
       UserStruct memory user;

       user.username = _username;
       user.age = _age;
       user.isUser = true;

       users[_userAddress] = user;
       userCount++;
       return true;
   }

Next we will create a getter to retrieve a particular value from our users mapping, in this case the "account" corresponding to an address.

function getUser(address _userAddress) public view returns (UserStruct memory){
       return users[_userAddress];
}

We will also create a function to keep track of the total number of users, we will call it getTotalUsers().

function getTotalUsers() public view returns (int) {
       return userCount;
}

Next, we will create a post. To do so, we will implement the createPost() function. The function defines a new instance of type Post, called newPost, and then it instantiates the values of it using the dot notation. Before returning true to indicate that a new post has been successfully created, the new post is added to the posts mapping using push().

  function createPost (
       address _userAddress,
       string memory _title,
       string memory _body
   )
   public returns (bool) {
       Post memory newPost;
       newPost.title = _title;
       newPost.body = _body;
       newPost.time = block.timestamp;

       posts[_userAddress].push(newPost);
       return true;
 }

Our dApp is almost ready. However, we still miss a way to retrieve the posts corresponding to a given address. To do so, we will implement the getPosts() method. The function takes the userAdddress and returns an array of type Post corresponding to the posts associated with the given address.

function getPosts(address _userAddress) public view returns (Post[] memory) {
       return posts[_userAddress];
}

Now we are ready to deploy our contract. We can compile our smart contract and deploy it. However, once we deploy it we might observe some unexpected behavior. We can call our getUser() function on an address that is yet to join the app. We do not want such behavior. To prevent this, we can use a require() statement in the getUser() function. This will return an error if we try to run getUser() for an address that has not "registered".

require(users[_userAddress].isUser == true, "User does not exist");

In a similar fashion, right now anyone can create a post using the createPost() function, even if they are not a user. To prevent this, we will use another require statement, this time in the createPost() function.

require(users[_userAddress].isUser == true, "User not registered");

The last thing we want to check, is if the user can only post in their name. To do so, we will use a third require statement to verify is the user is indeed the msg.sender.

require (_userAddress == msg.sender, "You can only post on your behalf");

That's all folks! I hope you found this short intro to Solidity helpful. If you are interested in more content like this you can find me on Twitter or join us at DevRel Uni.

Source Code:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.17;

contract SocialETH {

    struct UserStruct {
        string username;
        uint age;
        bool isUser;

    }

    struct Post {
     string title;
     string body;
     uint time;
    }

    mapping (address => Post[]) posts;
    mapping (address => UserStruct) users;
    uint userCount;

    function createUser (address _userAddress, 
string memory _username, 
uint _age) public returns 
(bool success){
        UserStruct memory user;

        user.age = _age;
        user.username = _username;
        user.isUser = true;

        users[_userAddress] = user;
        userCount ++;
        return true;
    }

    function getUser (address _userAddress) public view returns (UserStruct memory){
    require(users[_userAddress].isUser == true, "User does not exist");
    users[_userAddress];
    }

    function getTotalUsers () public view returns (uint) {
        return userCount;
    }

    function craetePost (
        address _userAddress,
        string memory _title,
        string memory _body
    ) 
    public returns (bool) {

        require(users[_userAddress].isUser == true, "User not registered");
        require (_userAddress == msg.sender, "You can only post on your behalf");
        Post memory newPost;

        newPost.title = _title;
        newPost.body = _body;
        newPost.time = block.timestamp; 

        posts[_userAddress].push(newPost);
        return true;
    }

    function getPosts(address _userAddress) public view returns (Post[] memory) {
        require(_userAddress == msg.sender,  "You can only post on your behalf");
      return posts[_userAddress];
    }
}

The Silver Bullet for 30-60-90 Day-Plans as a DevRel

Bianca Buzea — Sun, 26 Mar 2023 19:25:35 +0000

One of the first tasks when starting in DevRel, if not the first, is to do a 30-60-90 day plan. During DevRel Uni, I was often asked about the silver bullet for making a 30-60-90 day plan. The truth is, there is no silver bullet. It all comes down to the organization you are joining, its specific needs, focus, and stage of development.

However, there are certain activities that you should be doing in the majority of cases. Let’s cover those here.

The First 30 Days

The first 30 days are about learning about and establishing connections with your stakeholders. Consider colleagues from different teams (e.g., product, marketing, engineering, sales), external teams integrating with your protocol, top builders within your community, etc.). The conversations you have with these groups will help you understand the product, how it sets itself apart from competitors, relevant user personas, monetization strategy, and the maturity of the community.

You can start identifying what parts need improvement as you find answers to these questions. For example, maybe you find outdated tutorials or missing information in the docs. Identify opportunities like these to add value and strengthen the community (case studies, developer guides, events, advocacy programs).

Understand the organization's strategy over the long and short term, and see how your DevRel strategy can complement and fuel larger organizational goals.

Last but not least, set up a meeting with marketing as soon as possible and learn about the tone and voice of the brand. If you work in DeFi, or another field that abides by additional regulations, ensure you know the different rules concerning communicating with the community. To your surprise, you might even discover certain limitations when using emojis on Twitter.

At this stage, you should also get your first win. You’ll find a blocker that can be solved or start a small project that you are confident with. Your first win will boost your confidence and communicate to your team that they can rely on you.

Tip: while you are performing this learning exercise, document your learning. It can be as simple as daily tweets from your personal account. This will allow you to build relationships, collect feedback, and signal your new position as an advocate for the protocol.

Days 30-60

By now, you should be familiar with the protocol you are advocating for and its stakeholders and understand how DevRel is perceived internally. Ensure everyone is aware of the value that DevRel is bringing to your organization. Educate stakeholders about the critical role that DevRel is playing in your organization.

Now is the time to perform a developer experience audit. Put yourself in the shoes of a developer looking to integrate with your product and follow their journey. Go through your documentation, guides, code samples, and case studies. Repeat the same exercise for your competitors' products and take note of anything you should replicate or are missing. Work closely with the product team and loop them in on your findings. Document your experience and share it internally and externally (on social media or by creating blog posts).

Days 60-90

It is time to ramp up communication with the community. You should know by now where your expertise and knowledge can support and complement the DevRel team best. If it’s just you, identify how you will prioritize your activities and which efforts will get you the best returns.

With this information in mind, you can start actively publishing content for your organization. Start with written content (e.g., blogs, case studies), podcasts, events (meetups, plan for any future hackathons and conferences), and your usual social media activities (technical Twitter threads, Twitter spaces with partners, etc.).

You should aim to fix the most urgent needs first. In many cases, the most critical issues are around documentation. No matter how good a product is, if it isn't supported by good documentation, it pushes away potential users. Make a plan with the engineering team to best approach documentation, and start working on it together early.

Closing Thoughts

That’s a wrap. I hope by now you have a better understanding of the 30-60-90 day plan and are in a good position to start architecting yours.

If you want to learn more about the 30-60-90 day plan and how to break into DevRel, check out DevRel University.

Understanding Balancer: The Flexible Building Block for Programmable Liquidity

Bianca Buzea — Mon, 06 Mar 2023 19:33:37 +0000

Balancer is a DeFi protocol that provides liquidity infrastructure. You can build new, innovative liquidity pools and financial dApps on Balancer.

What is Balancer?
Who is Balancer useful for?
Why should I build on Balancer?
Batch Swaps, Flash Swaps, and Flash Loans

Let’s dive right in.

What is Balancer?

Balancer is a DeFi platform that offers a flexible building block for programmable liquidity. Balancer powers AMMs (Automated Market Makers) on the main EVM networks (Ethereum, Polygon, Arbitrum, Optimism, Fantom).

Balancer stands out thanks to its architecture. On Balancer, AMM pricing logic and math are handled independently from token accounting and management. This is accomplished by the Vault. The Vault contract manages the tokens from every Balancer pool. Consequently, builders can implement custom pricing logic and math without worrying about low-level token management and security. The Vault architecture also passes on reduced gas costs for users and enables efficient multi-step swaps (batch swaps) out of the box.
The flexibility of Balancer allows a diverse ecosystem of liquidity pools and AMM products to co-exist and reinforce one another.

Examples include:
Weighted pools allow users to limit their exposure to different assets in a liquidity pool. Instead of limiting depositors to 50/50 pairs, Balancer enables the creation of multi-token pools with custom weight parameters (e.g., 80/20, 60/20/20). This enables depositors to choose their exposure to different tokens in a pool. Swap fees can also be fully customized: high volatility pools usually have higher fees while low volatility pools have lower fees.

Liquidity Bootstrapping Pools are built to facilitate fair token launches. They are designed to disincentivize whales, bots, front-running, and speculation. They allow projects to define custom bonding curves that adjust over time. Projects that use LBPs can bootstrap liquidity with minimal investment. To get an idea of the potential of LBPs, Merit Circle raised an incredible $105,576,956 over the course of 72 hours using a Balancer Liquidity Bootstrapping Pool.

Boosted Pools are built to deliver high capital efficiency to LPs by enabling idle liquidity to be lent to external protocols. Typically, only up to 10% of the total pool liquidity is being utilized by swappers. This is because the average swap size and volume are much smaller than the total available liquidity at any given time. Boosted pools take advantage of this fact to offer depositors an opportunity at even greater returns.

Composable Stable Pools allow swappers to make significantly larger trades before encountering substantial price impact. Composable Stable Pools are nested, which means that they contain pool tokens as part of their pool. This defragments liquidity and saves users gas by allowing them to exit and join pools via the swap() function instead of the more expensive joinPool() and exitPool() functions.

Custom Pools are ideal for any team developing custom trade equations and strategies.
Since Balancer is permissionless, anyone can develop their own custom pool type and integrate it into the protocol. Some notable examples include Time-Weighted Average Market Makers (TWAMMs) developed by Cron Finance, the stablecoin design of Gyroscope, fixed-rate yield markets as developed by Element Finance, and AMM-powered remittance services (Xave).

Who is Balancer for?

Whether you’re an LP, swapper, or developer, Balancer has something to offer.

Developers: Improve your time to market by using Balancer’s secure building blocks
LPs: Make your liquidity work for you, provide liquidity and collect swap fees and BAL incentives
Swappers: Swap tokens safely for better rates across the entire Balancer ecosystem
Arbitrageurs: Perform Flash Loans with no fees having at your disposal the liquidity of the whole Balancer Vault

Why Should I Build on Balancer?

Balancer provides developers with secure DeFi infrastructure. Builders can focus on what differentiates their product/protocol. Balancer handles low-level token accounting, gas optimizations, and top-notch infrastructure security. This allows builders to ship faster, cheaper, and, most importantly, securely.
Building on Balancer can provide other important advantages, such as concentrated liquidity, streamlined integration with leading liquidity aggregators, and inclusion in the Balancer SDK, the SOR (Smart Order Router), and the Balancer Subgraph. Even more, teams building on Balancer can benefit from active support from different service providers in the Balancer ecosystem in areas like software development, marketing, and business development.

Batch Swaps, Flash Swaps, and Flash Loans

Batch swaps allow swappers to be positioned to get the best possible rates by efficiently accessing every Balancer pool's liquidity. This is useful when getting the best rate requires performing multiple swaps. With other protocols, you would pay gas for sending tokens at every step. However, with Balancer, since all the tokens are in the Vault contract, you only need to make a single function call where tokens are transferred only between you and the Vault.

You can execute a Flash Swap if you discover an arbitrage opportunity in two Balancer Pools. You don’t need to hold any tokens to take advantage of it. You can use the Vault’s liquidity to make such trades without paying a fee while keeping all the profit. Anyone who identifies a price discrepancy in two Balancer Pools can freely take advantage of it.

Fig1: A Flash Swap in Practice (Etherscan)

You can even use Flash Loans for arbitrage opportunities across the whole DeFi ecosystem. Arbitrageurs who use Balancer’s Flash Loans have the unique advantage of having access to the entire Balancer’s liquidity while paying no fees for the Flash Loan.

Closing Thoughts

In summary, Balancer is a DeFi platform that provides liquidity infrastructure that helps accelerate innovation. Whether you're a developer, liquidity provider, swapper, or arbitrageur, you can take advantage of Balancer’s unique features.
As a developer, you can benefit from secure DeFi infrastructure, enabling you to focus on building innovative DeFi applications while Balancer handles low-level token accounting and gas optimizations. To begin building on Balancer, check out the documentation at docs.balancer.fi and learn more about how to get started.

This article is for informational and educational purposes only, and should not be construed as investment or trading advice or a solicitation or recommendation to buy, sell, or hold any digital assets. Transactions on the blockchain are speculative. Carefully consider and accept all risks before taking action.