This article was originally posted on the Formo Blog.

Building a successful onchain app is hard. It gets even harder when you don’t know how people are using it. You’re shipping features, running campaigns, and trying to find product-market fit, but without clear data, you’re lost in a dark forest. Analytics remains as one of the biggest challenges in crypto.

Think about the questions you’re trying to answer every day:

• Who are my top users?
• What drove them to us? Where do they come from?
• Which channels or campaigns are working?
• How are users using my app?
• What’s my CAC? LTV? ROI?
• What is moving the needle onchain?

To answer the above in web3 you’d need an in-house data team, complicated data pipelines, and juggle multiple fragmented tools. What if there’s an easy way to understand who your users are and what they do so you can build a better app, faster?

This article was originally posted on the Formo Blog.

Developer tools remove barriers to innovation. Analytics remove barriers to growth

Data is the lifeblood of any business. It helps you understand your customers and where they came from, make impactful data-driven decisions, and drive sustainable growth. Without data, you’re lost in a dark forest.

However, understanding onchain user behavior is hard. Teams struggle to set up analytics and attribution from fragmented tools, data pipelines, and databases. Many teams give up altogether.

Formo is the data platform for onchain apps. Formo makes analytics easy for crypto. Get the best of web, product, and onchain analytics on one versatile platform.

gm! It’s been a long while. 👋

Onchain summer is here. A new wave of consumer crypto apps is coming. 🕶️

What if there is a hardcoded contract address in another contract you need to test? External dependencies in smart contracts are sometimes stored as immutable and constant variables:

contract Vault {
  // An external dependency hardcoded at a specific address
  IOracle public constant oracle = IOracle(0x773616E4d11A78F511299002da57A0a94577F1f4);

  function foo() {
    ...
  }
}

In unit tests, we may need to modify external dependecies to produce specific answers behaviours and test multiple scenarios.

We can use forked mainnet and testnet networks to test against live external dependencies locally. However, hardcoded addresses prevent us from swapping them out with a local version deployed at another address. We need a way to mock an already deployed contract at a specific hardcoded address.

How can we replace the bytecode of an existing contract?

Let’s say that you have a contract A which makes a low-level call or delegatecall to another contract B:

contract A {
  function foo(address target, bytes data) external {
    (bool success, bytes memory result) = target.delegatecall(data) // used to call B.bar()
  }
}

The target contract B reverts with a revert message or custom error:

contract B {
  error AccessForbidden(address sender);

  function bar() external {
    revert AccessForbidden(msg.sender);
  }
}

How can you bubble the error up in contract A?

The goal of smart contract audits is to assess code (alongside technical specifications and documentation) and alert project team of potential security issues that need to be addressed to improve security posture, decrease attack surface, and mitigate risk.

An audit helps to detect and resolve security issues before launch, summarized as a set of findings with underlying vulnerabilities, severity, difficulty, sample exploit scenarios, and recommended mitigations.

Given the high cost of smart contract bugs, it’s no surprise that an audit is a key step in the smart contract development lifecycle. However, engaging an auditor can be costly and difficult due to high demand.

In this article, we’ll learn how you can use the open source tools Slither and Echidna to audit Solidity contracts, in order to identify any potential security vulnerabilities.

In a previous post, we learned about forking mainnet as an alternative to mock contracts in Solidity. The major drawback with mock contracts is that you need to spend time to rewrite existing smart contracts as mocks. To get exhaustive mock coverage, you’ll end up rewriting whole protocols for the sake of testing.

What if there’s a magical way to mock contract functionality without writing mock contracts? Read on to learn more.

Ethereum and other permissionless blockchains are innovation machines. Developers are free to build with completely public building blocks, stitching them together to create sophisticated systems out in the open.

When building a protocol of your own (DeFi, NFTs, etc), you’ll quickly realize that you need to interface with existing contracts. In a single transaction, your contracts may call several others. These contracts may include DeFi lending protocols, AMM pools, and marketplace contracts that are live on mainnet.

Interfacing with other protocols is a key part of smart contract development. But how do you develop against these building blocks?

Let’s hunt for an answer.

Computations on Ethereum cost gas. If you’re not careful, you may end up writing contracts that cost more than they should. High gas costs kill usability!

A common cause for high gas costs is an inefficient storage layout in Solidity contracts. In this post, let’s look at some tips you can use to help you write more gas-efficient contracts.

Read on to learn more!

Recently is a periodic retrospective.