Every blockchain project starts with a dream and a limited budget. At Frak, we built a platform for automated on-chain reward distribution that powers marketing campaigns through smart contracts. Running entirely on Arbitrum, our infrastructure needs to handle:

• High-frequency events: Processing ~8 user tx per week per active user
• Complex queries: Real-time analytics and reward calculations
• Multi-contract indexing: 8 master contracts and 3 active factories (with, at the time of writing, ~100 contracts deployed).

When your core business logic lives on-chain, your infrastructure needs to be bulletproof while keeping costs under control. Here’s how we built it using open-source tools.

The Challenge

Every blockchain application faces three core challenges:

1. Reliable and cost-effective RPC access
2. Efficient event indexing and data access
3. Scalable infrastructure that doesn’t break the bank

Most teams throw money at the problem. We took a different approach.

eRPC: Your Chain’s Traffic Controller

eRPC is like the air traffic controller for your blockchain requests — but one that also has a photographic memory and cost-optimization superpowers. Written in Go for maximum performance, it’s a fault-tolerant EVM RPC load balancer that makes your typical proxy look like a rusty gate.

Key Features That Made Us Choose eRPC

Intelligent Load Balancing

• Per-method routing (because let’s face it, not all RPCs are created equal)
• Project-specific configurations (different strokes for different folks)
• Automatic fallback handling (because uptime is not just a nice-to-have)

Smart Caching

• Reorg-aware permanent caching (no more stale data nightmares)
• Method-specific cache rules (cache what matters, ignore what doesn’t)
• Selector-level granularity (because sometimes you only need to cache specific contract calls)

Developer Experience Superpowers

• Need to scale your dev team? Got smart contract tests hitting your RPC like a MEV bot during an airdrop? eRPC’s project system lets you:
• Create dedicated environments for different teams
• Implement IP-based or wallet signature auth
• Configure aggressive caching for test environments
• Zero config changes for developers (it just works™)

Power in Simplicity

Want to see how easy it is to do complex things? Here’s an eRPC config that handles multi-provider load balancing, rate limiting, method-specific routing and caching:

export default initErpcConfig({
    logLevel: "info",
    database: {
        // Here you can list every db used (pg, redis, in memory etc), and then config which one are used depending on the type of data, or even the method used
        // Frak config here: https://github.com/frak-id/infra-blockchain/blob/6e907c50db2117083a113ee74e2d38d1a6b596ea/packages/erpc/src/storage.ts
        evmJsonRpcCache: cacheConfig,
    },
})
    .addRateLimiters({
        // Yup, you can even go in depth with per method rate limiting
        alchemy: [{ method: "*", maxCount: 300, period: "1s", waitTime: "5s" }],
        pimlico: [{ method: "*", maxCount: 100, period: "1s", waitTime: "5s" }],
        drpc: [{ method: "*", maxCount: 100, period: "1s", waitTime: "5s" }],
        // And yup, rate limits can also be applied to networks, auth strategies, projects, etc
        walletProject: [{ method: "*", maxCount: 1000, period: "1s", waitTime: "5s" }],
    })
    // Add a few networks to the config
    .decorate("networks", {
        arbitrum: arbNetwork,
        arbitrumSepolia: arbSepoliaNetwork,
    })
    // Add a few upstreams to the config
    // Frak upstreams config: https://github.com/frak-id/infra-blockchain/blob/main/packages/erpc/src/upstreams.ts
    .decorate("upstreams", {
        alchemy: alchemyUpstream,
        drpc: drpcUpstream,
        pimlico: pimlicoUpstream,
    })
    .addProject(({ store: { upstreams, networks } }) => ({
        id: "wallet-rpc",
        // Smart routing: Pimlico for AA, Alchemy for everything else, dRPC as fallback
        upstreams: [
            upstreams.alchemy,
            upstreams.pimlico,
            upstreams.drpc
        ],
        networks: [networks.arbitrum, networks.arbitrumSepolia],
        // Rate limiting with the budget defined before
        rateLimitBudget: "walletProject"
    }))
    .build();

In this example we are using the erpc-config-generator package that provide the builder pattern, you can also directly use the erpc typescript config.

Our Production Setup

And here’s how eRPC makes blockchain load balancing and multi-RPC routing look easy and helps us achieve virtually no downtime:

Indexing Projects

• Primary: Envio + dRPC
• Fallback: Alchemy
• Why? Cost optimization for high-volume historical queries

General Purpose (Frontend + Backend + Foundry)

• Primary: Alchemy + Pimlico
• Fallback: dRPC
• Auxiliary: Free RPCs for non-critical paths

Ponder: The Indexer That Sparks Joy

If you’ve ever wrestled with The Graph’s hosting service, Ponder feels like a warm hug from your favorite dev tool. It’s the indexer that makes you remember why you loved blockchain development in the first place.

// Track when a campaign distribute a reward
ponder.on("CampaignBanks:RewardAdded", async ({ event, context }) => {
    // Try to find a rewarding contract for the given event emitter
    const bankingContract = await context.db.find(bankingContractTable, {
        id: event.log.address,
    });
    if (!bankingContract) {
        console.error(`Banking contract not found: ${event.log.address}`);
        return;
    }

    // Update the total amount of distributed token for the rewarding contract
    await context.db
        .update(bankingContractTable, {
            id: event.log.address,
        })
        .set({
            totalDistributed:
                bankingContract.totalDistributed + event.args.amount,
        });

    // Update the current user reward (insert it if not found)
    await context.db
        .insert(rewardTable)
        .values({
            contractId: bankingContract.id,
            user: event.args.user,
            pendingAmount: event.args.amount,
            totalReceived: event.args.amount,
            totalClaimed: 0n,
        })
        .onConflictDoUpdate((current) => ({
            pendingAmount: current.pendingAmount + event.args.amount,
            totalReceived: current.totalReceived + event.args.amount,
        }));

    // Insert the reward event
    await context.db.insert(rewardAddedEventTable).values({
        id: event.log.id,
        contractId: bankingContract.id,
        user: event.args.user,
        emitter: event.args.emitter,
        amount: event.args.amount,
        txHash: event.log.transactionHash,
        timestamp: event.block.timestamp,
    });

    // Update the current campaigns stats for the distributed amount
    await safeIncreaseCampaignsStats({
        productId: bankingContract.productId,
        context,
        blockNumber: event.block.number,
        increments: {
            totalRewards: event.args.amount,
        },
    });
});

Real-World Indexing at Frak

We’re not talking about toy contracts here. We’re indexing:

• 8 master contracts
• 3 active factory contracts
• On Arbitrum (hello, short block times 👋)
• Complex marketing campaign tracking
• Real-time statistics generation

Why Ponder Won Our Hearts

Blazing Fast Indexing

• Reindexing that doesn’t require a coffee break
• Internal caching that makes updates feel instant
• Direct PostgreSQL integration that just works

Real-world Performance

• Handles complex on-chain marketing campaigns
• Real-time statistics generation
• Shared database with Web2 backend (bye-bye, unnecessary data transfer)

Developer Experience That Doesn’t Suck

• TypeScript all the way down
• Built-in HTTP server via Hono
• Caching and rate limiting included

Deployment: Because YOLOing to Production is So 2017

SST v3 orchestrates our entire deployment with the elegance of a perfectly executed flash loan:

Infrastructure as Code Benefits

• Zero-touch deployments
• Version-controlled infrastructure
• Easy environment replication
• Pulumi under the hood (because when we eventually move to k8s, we won’t need therapy)

Open Source All The Way Down

Every tool in our stack is open source and actively maintained:

• eRPC: The RPC infrastructure that scales with you
• Ponder: The indexer that just makes sense
• SST: Infrastructure as code that doesn’t make you cry

Want to see how it all fits together? Check out our blockchain infrastructure repo for the complete picture.

Bootstrap Like a Chad, Spend Like a Bear Market

Here’s the secret sauce for launching your blockchain infrastructure without needing a Series A: smart use of free tiers and efficient architecture. Think of it as yield farming cloud credits and RPC calls.

The Zero-to-One Infrastructure Stack

Cloud Foundation 🌩️

• AWS Free Tier = 12 months of free t2.micro instances
• GCP = $300 initial credits
• Choose your poison, both work great with our stack

RPC Strategy 🔌

.addProject({
  id: "bootstrap-rpc",
  upstreams: [
    // Free RPCs, strategically load balanced
    llamaNodes,     // 25k requests/day
    publicNodes,    // Variable limits
    ankr.free,      // 20k requests/day
    // Add more as you grow
  ]
})

Indexing & API 📊

• Self-hosted Ponder = $0 (runs on your free tier instance)
• PostgreSQL = Free tier on cloud provider
• Hono endpoints = Comes free with Ponder

Cost Breakdown for MVP

• Infrastructure: $0 (cloud credits)
• RPC Calls: $0 (load balanced free tiers)
• Indexing: $0 (self-hosted)
• Your time: Minimal (thanks to these tools)

When You’re Ready to Scale 📈

Hit the free tier limits? Congratulations, you’ve got traction! When it’s time to graduate from farming free RPCs, check out eRPC’s aggregator service. It’s one unified endpoint for all chains with pre-negotiated provider rates. They’ll even host the eRPC instance for you if infrastructure management isn’t your thing.

The Results

This setup has allowed us to:

• Start lean (your VCs will thank you)
• Scale smoothly as user base grew
• Maintain high reliability
• Keep infrastructure complexity manageable
• Process complex on-chain marketing campaigns in real-time

What’s Next?

While our current setup is solid, we’re exploring:

• Kubernetes migration for more deployment flexibility
• On-premise solutions for cost optimization
• Further RPC usage pattern optimization

Conclusion

Building blockchain infrastructure doesn’t have to feel like solving a Rubik’s cube blindfolded. With open-source tools like eRPC, Ponder, and SST, you can build a robust, scalable system that grows with your needs.

At Frak, this infrastructure powers a platform that’s revolutionizing brand advocacy:

• Real-time reward distribution for authentic shares
• Transparent, cost-effective customer acquisition
• Direct value flow from brands to advocates
• Scalable word-of-mouth marketing automation

The best infrastructure is like a good smart contract — it just works, and you only notice it when something goes wrong. And when 87% of people read reviews before purchasing and 79% trust customer reviews like friends’ recommendations, you really can’t afford for things to go wrong.

Building Cost-Effective Blockchain Infrastructure: A Journey with eRPC and Ponder was originally published in frak-defi on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hey there, fellow blockchain enthusiasts and developers! 🚀 In this piece, we’re diving deep into the nitty-gritty of leveraging WebAuthN signatures for validating user operations within the exciting world of ERC-4337 smart accounts.

You might remember our initial foray into this topic, co-authored with Yoan from the Cometh team. If you haven’t checked it out yet, do yourself a favor and give it a read here. It sets the stage for what we’re about to explore and showcases some pioneering work in the field.

Before we jump in, let’s make sure we’re all on the same page. This article assumes you’ve got a good grasp on ERC-4337, along with key concepts like Bundlers, Paymasters, SmartAccounts, and the broader idea of account abstraction. If you’re thinking, “Wait, slow down!” — no worries, we’ve got you covered. Check out these fantastic resources to get up to speed:

• ERC-4337 Documentation
• ERC-4337 overview by Stackup

Ready? Let’s get started on this adventure together!

Context

In our journey at Frak Labs, as we’ve previously touched upon in our collaboration with Yoan, our mission is to create blockchain tools designed with non-crypto natives in mind. One of the biggest hurdles we’ve consistently bumped into? Friction. Yep, that old nemesis. Friction is the archenemy of user acquisition. The traditional setup process — getting started with MetaMask, jotting down a seed phrase, and having to purchase tokens just to cover gas fees — can feel like running an obstacle course for newcomers.

Account abstraction comes to the rescue, at least for the last bit concerning gas fees. It’s a game-changer, allowing platforms to either sponsor user operations or let users pay for transactions with the platform’s own tokens, smoothing out one significant bump on the road.

However, the current landscape for smart accounts often leans on the crutch of an existing External Owned Account (EOA), be it through MetaMask, Ledger, or a somewhat “hidden” EOA behind a Multi-Party Computation (MPC) system, like Turnkey or Web3Auth. But here’s the rub: neither option clicked for us. The first scenario still demands users to set up an EOA beforehand — a no-go for true ease of use. The second? It paradoxically forces us to depend on a centralized platform for access to decentralized goodies. Quite the conundrum, right?

This conundrum led us down a rabbit hole of research until we pioneered a novel solution that seamlessly integrates WebAuthn and account abstraction, enabling a truly frictionless onboarding experience for non-crypto natives. While solutions like Cometh’s also provided a smooth connect experience, our approach was tailored to our ecosystem, especially with our kernel accounts at the core.

The Solution: Simpler on Paper

On paper, the solution to our user friction problem sounds straightforward. To execute a user operation, all we need is validation, ideally without the hassle of an External Owned Account (EOA). Enter WebAuthN, the hero we’ve been looking for. It offers a neat way to secure a signature from the user for a 32-byte piece of data on the P256 curve, utilizing either their device or an external secure device that supports this curve.

So, in theory, the process should be as simple as: prepare the user’s operation, get it signed, and voila, send it off with the correct signature attached. Sounds like a dream, right? Well, as we soon discovered, reality had other plans.

Trailblazing Integration: Cometh’s WebAuthN Breakthroughs

Cometh has been a true pioneer in the realm of WebAuthN and blockchain integration, their innovative solutions tackling some of the most formidable challenges in this space. A pivotal breakthrough was their integration of the P256 curve — an essential component of WebAuthN signatures that was previously incompatible with blockchain environments.

Cometh, collaborating closely with Renaud Dubois from Ledger and his talented team, was the first to leverage Dubois’ optimized on-chain P256 verifier. This ingenious solution enables the blockchain to validate signatures from the P256 curve efficiently, overcoming a major compatibility hurdle without incurring prohibitive gas costs.

At Frak, we have built upon this groundbreaking work, introducing our own innovations to seamlessly integrate WebAuthN and the P256 curve into our Kernel smart wallet architecture.

While Cometh paved the way as the first team to utilize Dubois’ verifier, our focus has been on tailoring and enhancing the implementation to meet the unique requirements of our ecosystem. From optimizing gas costs to ensuring a frictionless user experience, we have developed novel approaches that unlock new possibilities for WebAuthN adoption within our kernel accounts and beyond.

Navigating the P256 Curve with WebAuthN

When it comes to integrating WebAuthN into blockchain operations, the use of the P256 curve presents a unique challenge. Contrary to what one might expect, the standard doesn’t sign the 32 bytes of data you send directly. Instead, what gets signed is essentially a “double” hash of a JSON payload containing the challenge, authenticator data, and additional verification data. This complexity is not for naught; it ensures the integrity and authenticity of the signing process, verifying that the right user, with the right device, signs off on the operation. However, this mechanism also obscures the challenge by embedding it within a JSON structure.

So, the question arises: How do we verify that the user operation hash was indeed signed by our user?

The answer is less straightforward than one might hope. To achieve this, we must embrace the complexity head-on. The process involves forwarding all the relevant data from the WebAuthN signature process (authenticator and verification data) to the blockchain, ensuring the presence of the challenge within the authenticator data, and then proceeding with the “double” hash operation to verify the signature against this computed hash.

Currently, there are two prominent approaches to this challenge:

• FCL Method (championed by Renaud Dubois): Favoured by Cometh and us, this method involves encoding the data in base64 to minimize calldata size, followed by a base64 search operation using bytes. This approach not only optimizes on-chain operations but also reduces the amount of calldata transmitted.
• Daimo Approach: This method opts to transmit all data in its original JSON format, performing an on-chain string search to locate the challenge, before reconstructing and verifying the double hash.

We opted for the FCL method, tweaking it slightly to align with the specifications of our kernel validator and to further reduce gas costs for these specific use cases. This decision was driven by the perceived efficiency of the FCL method in terms of on-chain operations and calldata management. Although we have not conducted extensive benchmarks to confirm our hypothesis (pending the acceptance of a PR for benchmarking different validator types by Kernel), our preliminary analysis suggests this to be the more streamlined approach.

Tackling Paymaster Gas Estimation

As we peel back the layers of the user operation flow, especially when it’s sponsored, let’s sketch out what this looks like:

At first glance, this process might seem straightforward (maybe because I’ve simplified it a bit too much, haha), but there’s a critical step that might trip us up. Not spotting it yet? Let’s take a closer look at the Paymaster data computing stage.

Here’s where things get tricky. The Paymaster data computation happens before we request the signature — logical, since we’re signing the entire bundle, including Paymaster data. But, how does the Paymaster predict a transaction’s cost before actually executing it?

The answer is simpler than you might think: by running a transaction simulation with the call data and a dummy signature to validate the user operation. This simulation helps estimate the gas cost, determining if the project can cover it, and then calculates all the necessary Paymaster specifics (like verification gas). The challenge, however, lies in the on-chain P256 verification and the signature formatting steps, which are gas-intensive. How do we ensure a dummy signature can navigate through these steps without causing an early exit?

Creating a dummy signature that doesn’t prematurely exit during the formatting process seemed impossible without designing a custom Paymaster contract and server specifically for this scenario — not the most ideal solution.

That’s why I introduced a bypass in the signature formatting step — yes, the double hash part. When the data is clearly incoherent, this bypass allows the process to continue as if everything were normal, directly returning the provided challenge instead of the double hash value (as you can see here).

However, this bypass alone isn’t enough. We also needed a signature that wouldn’t trigger an early exit during the P256 verification step. After some exploration within the FCL contracts, we found the perfect signature to proceed.

Just when you think you’ve got it all figured out, there’s another twist. Remember our little double hash bypass? Or the fact that authenticator and verification data can’t be known in advance? Preparing a dummy signature requires packing it with enough calldata — so much so that the calldata and its parsing compensate for the bypass. And that’s how we end up with a dummy signature, brimming with uint256.max values, repeated 40 times.

Streamlining On-Chain P256 Verification with RIP-7212

Alright, we’ve navigated through the intricate world of WebAuthN signatures, tackled the unique challenges of integrating them with blockchain operations, and devised ways to simulate transactions accurately. So, what’s the final hurdle in our journey? The on-chain verification of P256 signatures.

P256 verification on-chain has always been a tough nut to crack. Despite the brilliant optimization efforts (huge shoutout to Renaud for his exceptional work), we’re still looking at around 200k gas for just verifying a P256 signature.

Enter RIP-7212: a beacon of hope designed to significantly reduce this cost. RIP-7212 proposes adding a pre-compiled smart contract to rollups, specifically for P256 signature verification — akin to the efficiency of ecrecover or sha256.

However, as is often the case with cutting-edge solutions, RIP-7212’s recent finalization means its widespread availability is still on the horizon (currently, it’s only operational on Polygon Mumbai). This poses a question: How do we create an immutable validator without forcing our users through a costly migration once RIP-7212 becomes universally available, especially considering we aim to avoid any validator storage access?

The solution? Introduce a new flag within our signature protocol. This flag allows users to choose between the traditional on-chain P256 verification and the new, more efficient pre-compiled verification method. Of course, attempting to use the pre-compiled verification on a chain that doesn’t support it yet will result in failure. To address this, we’ve added a simple external function to the validator that checks for pre-compile support on the chain. During the initialization of the web2 client, this function is called to verify support; if pre-compile is available, we automatically adjust the signature flag for all subsequent operations.

Conclusion

And there you have it — a whirlwind tour through the intricacies of integrating WebAuthN with ERC-4337 smart wallets, navigating the P256 curve, and streamlining the process with innovations like RIP-7212. It’s been a journey of discovery, challenge, and ultimately, innovation, showcasing the power of collaboration and the relentless pursuit of making blockchain technology more accessible and efficient.

If you found this deep dive enlightening, please give us a clap and share this article with your network. Your support fuels our continued exploration and sharing of breakthroughs in this exciting domain. Stay tuned for more posts as we further unravel the journey of WebAuthN implementation and its transformative potential in the blockchain ecosystem. Until then, happy coding, and let’s keep pushing the boundaries of what’s possible together!

Unlocking the Future: WebAuthN Meets ERC-4337 Smart Wallets was originally published in frak-defi on Medium, where people are continuing the conversation by highlighting and responding to this story.

Welcome to an exciting milestone at Frak-Labs! Before we unveil our latest Proof of Concept (POC) and the unique challenge it aims to tackle, let’s take a moment to revisit our roots and the journey that brought us here.

At the heart of Frak-Labs, our mission emerged from witnessing transformative shifts within the content market, initially inspired by the burgeoning creator economy. However, as we navigated through this evolving landscape, we uncovered a series of persistent challenges. Central to these was the issue of centralization — a system where intermediaries disproportionately benefited at the expense of creators and publishers, eroding the profits meant for those who actually create value.

Moreover, publishers face a slew of emerging hurdles: the impending end of cookies, an oversaturated subscription model leading to subscription fatigue, and a noticeable decline in household spending on subscriptions. These challenges not only threaten the sustainability of content publishing but also stifle innovation and fairness within the ecosystem.

Building on the success of our MVP, which introduced a novel revenue stream for content creators by rewarding users for their engagement and investment in content, we’re now setting our sights on addressing a critical question: How can we revolutionize the content publishing space?

This ambition led to the creation of our latest POC, leveraging the power of WebAuthN based smart wallets and account abstraction to unlock unprecedented potential within the Frak ecosystem. Stay tuned as we unveil the details of this innovative solution, designed to empower creators and publishers alike, paving the way for a more equitable and decentralized content market.

Disclaimer: This is a Proof of Concept (POC), not ready for production and runs on the Polygon Mumbai testnet. Please refrain from transferring real assets to wallet addresses, and be prepared for potential bugs. Your feedback is valuable as we work towards improvement.

Why This POC?

High churn rates in the newspaper market sparked our initiative. Users often back away at the sight of a paywall — discouraged by the tedious steps of account creation, entering payment details, and navigating through subscriptions. Not to mention, the high fees that companies incur with each subscription add to the dilemma.

Our journey with the MVP taught us valuable lessons about user experience. We’ve been creating numerous wallets, aiming for the simplest UX possible. This experience led us to believe in a better solution.

Enter the world of smart wallets and account abstraction. This sector is on fire with innovations. Technologies like WebAuthN stand out, promising a future where accessing wallets through biometrics is streamlined, yet remains decentralized — no complex setups like MPC needed.

This sparked an idea: What if we could eliminate traditional paywalls by instantly creating wallets for users? Imagine swapping the convoluted subscription process for a quick biometric check.

That’s the core reason behind our POC. We’re on a mission to show how blockchain technology can meet real-world needs. Imagine unlocking an article or subscribing with a few tokens — all made simple, aiming to reduce churn rates for newspapers.

Using a smart wallet for these tasks offers more than convenience. It allows for anonymous tracking of reader preferences — like favorite articles and topics — without invading privacy. As the era of cookies ends, this presents a privacy-centric solution for content providers.

The Demo Itself

Dive into our Proof of Concept (POC) through this hands-on demo. It’s designed to showcase the seamless integration of our technology in real-world scenarios. Here’s what makes up the demo:

1. Frak-SDK

• A simple SDK for content publishers to integrate with the Frak ecosystem easily.
• Provides user-specific information for content, such as unlock status, pricing, and balance checks.
• Fully offchain compatibility, perfect for PWA apps distributing content with the Frak wallet installed — ensuring no connectivity issues.
• Secure communication through various methods including verification hashes, data obfuscation, and origin checks.

2. Newspaper Website

• A straightforward implementation showcasing an article without any blockchain or external API knowledge.
• Utilizes Frak-SDK to obtain real-time access information (user permissions, pricing for unlocks) and initiates the unlock process.

3. The Wallet Website

• A Progressive Web App (PWA), installable on phones for offline use.
• Built using account abstraction (thanks to ZeroDev for the Kernel account, and Pimlico for the bundler and paymaster).
• Account creation and transactions are WebAuthN enabled, allowing for biometric operations.
• Soon to support multiple asset types and integration with WalletConnect, making it usable on any dApp in the market.
• Handles Frak-SDK requests, facilitating communication with the content provider.

What the Demo Showcases:

• Kernel wallet creation and recovery using only biometrics — no backend required.
• Wallet interactions solely through biometrics.
• Secure cross-domain communication client-side, enabling smooth operation on offline devices.
• A glimpse into the future of content paywalls, leveraging blockchain for a frictionless user experience.

Visual Demonstrations:

This GIF guides new users from clicking the unlock link at the bottom of an article through the intuitive setup and use of the wallet.

Experience the Flow Yourself:

1. Start by visiting our FrakDemo Twitter account at https://twitter.com/FrakDemo to find a selection of article links.
2. Click on “Unlock with FRK” after selecting an article, and then pick a pricing option.
3. Simply follow the prompts — a seamless process requiring no more than three clicks to complete the flow (or just two clicks if you already have a wallet!).
4. Dive into your chosen content and enjoy.

Additional Tips:

• Checking Your Wallet: Visit poc-wallet.frak.id to view your wallet. If you aren’t automatically logged in after an article unlock or purchase — something that might occur on Apple devices due to their specific sandboxing — don’t worry. Simply use the Recover wallet feature with the same passkey from the unlocking process to regain access to your wallet.
• What to Expect in Your Wallet: For now, the wallet page may look a bit sparse, but expect this to change dramatically in the next few weeks. You’ll currently find a history section with links to your unlocked articles. In the settings, there’s an option to acquire test FRK tokens, allowing for further exploration of the flow. Rest assured, we’re working on enriching the wallet’s functionalities and interface, aiming to significantly enhance your experience shortly.

How Does It Work Under the Hood?

Got a flair for the technical? If you’re the kind who enjoys puzzles more complex than trying to find your way in a new city without GPS, here’s a treat. Check out our sequence flow diagram — it’s like the blueprint for a secret tech lair, minus the secret handshake: https://github.com/frak-id/wallet/blob/main/docs/graphs.md

Integrating a smart wallet with a WebAuthN validator introduces complex challenges, prominently the domain lock issue, which significantly influenced our architecture:

• Domain Lock Challenge: Passkeys are restricted to a specific domain — our case being frak.id. They are only functional within this domain, affecting both their creation and use for signing transactions.

This challenge led us to develop an SDK that simplifies the interaction between content providers and our wallet, making transaction initiation straightforward:

• SDK Overview: Our SDK enables content providers to fetch user-specific details like content unlock status, pricing, and balance. Designed for full off-chain functionality, it ensures seamless operation, even in PWA apps, without connectivity issues.
• Secure Transmission: Data security is paramount, achieved through obfuscation and multiple verification layers. Future updates will incorporate asymmetric signatures or HMAC for even stronger security.

Transaction Process: Upon requesting a transaction, users are redirected to their wallet page or app, filled with necessary transaction details. After validation, the user is prompted to authorize the transaction. Thanks to collaboration with Pimlico and their SDK, the transaction is then bundled and sent to the bundler, facilitating a swift user experience without unnecessary wait times on the wallet page.

Communication Between Content Provider and Wallet: Maintaining a secure and efficient communication line is crucial. Post-transaction, content providers can query the wallet for the transaction’s status, ensuring a seamless flow of information.

Implementing Secure and Efficient Communication: We faced the challenge of ensuring robust communication that supports offline access and is easy for publishers to integrate, regardless of their technology stack. Our solution involves using an iframe for secure, cross-domain communication, establishing a direct and secure channel within the browser environment.

Security and Accessibility: Security and user-friendliness are our top priorities. We’ve designed the system to be inclusive, allowing for easy integration across various technology levels while ensuring a secure exchange of information to prevent fraudulent access.

Future Directions: We plan to expand the SDK features, including signature requests and external APIs, based on publisher feedback. This POC is a glimpse into a future where digital content is more accessible, potentially eliminating traditional paywalls and introducing new monetization strategies for content providers.

What’s Next?

As we forge ahead, our team is thrilled to enhance the demo of our wallet with an array of new functionalities in the coming weeks:

1. Global ERC-20 Asset Management: Users will soon be able to receive, send, and track a variety of assets directly within the wallet’s UI, making asset management seamless and intuitive.
2. Expanded Content Unlocking Demos: We’re exploring beyond articles — what would you like to unlock next? Cinema tickets? Music streaming access? Let us know your thoughts!
3. NFT Asset Handling: The integration of NFTs is on our roadmap, enabling users to manage their digital collectibles and art within our ecosystem.
4. WalletConnect Integration: To ensure our wallet’s versatility, we’ll introduce WalletConnect support, allowing it to be used on any website.

Following these updates, our focus will shift towards developing a production-ready version of the wallet. In collaboration with our partners, we’ll launch an alpha release to our current users for thorough testing. This phase is crucial for ensuring reliability and user satisfaction.

Once we’re confident in the wallet’s performance, we’ll roll it out for public use. This means you could soon experience the convenience and security of our WebAuthN-based smart wallet firsthand.

Stay tuned for these updates and more as we continue to innovate at the intersection of blockchain technology and user experience. Together, we’re not just building a wallet; we’re shaping the future of digital interactions and transactions.

Acknowledgments

We’d like to extend our heartfelt thanks to the teams and individuals who’ve played a crucial role in bringing this POC to life:

• Yoan from Cometh: An expert in the WebAuthN space whose guidance has been indispensable throughout our journey.
• ZeroDev: For providing the foundational Kernel smart wallet technology and invaluable support during the custom validator implementation.
• Pimlico: For their permissionless SDK, bundler, and paymaster services that have been instrumental in our development process, along with their ongoing support.

This project stands as a testament to the power of collaboration within the blockchain community. A big thank you to everyone involved for their contributions, insights, and unwavering support.

Conclusion

As we reach the end of this journey together, we hope you’ve found inspiration and insight in the possibilities that our Proof of Concept opens up — not just for content publishing but for the broader landscape of digital interactions. Our journey is far from over, and your support plays a pivotal role in shaping its direction.

We warmly invite you to:

• Clap and Share: If this article resonated with you, please don’t hesitate to applaud it and share it within your networks. Each clap and share not only amplifies our message but also fuels our passion and commitment to innovation.
• Explore the Demo: Dive into the experience yourself by exploring our demo. Witness firsthand the simplicity and power of our solution, and if it inspires or excites you, we’d be thrilled if you shared it with others who might appreciate it as well.

This project is a testament to the power of collaboration, innovation, and community support. Together, we’re not just imagining the future — we’re actively building it. So, whether you’re a developer, content publisher or creator, or simply an enthusiast for cutting-edge technology, your engagement, feedback, and shares are invaluable to us.

Let’s continue to break new ground, challenge the status quo, and reshape the world of digital content together. Thank you for being an integral part of our journey.

Your voice, your support, and your curiosity are what drive us forward. Let’s make waves, together.

Further Reading

Dive deeper into our exploration and collaborative insights with this curated list of articles on Medium. These pieces, co-authored with Yoan from Cometh, delve into various facets of blockchain technology, smart wallets, and our journey in developing this POC:

• Explore Our Collaborative Articles on Medium

This collection provides a comprehensive look at our collaborative efforts, offering valuable perspectives and insights into the evolving landscape of blockchain technology.

From Idea to Innovation: Unveiling Our WebAuthN Smart Wallet Demo was originally published in frak-defi on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hey there, blockchain enthusiasts and savvy developers!

Ready to delve into a story of innovation and transformation in the blockchain universe? Today, I’m thrilled to share with you Frak’s journey, where we transitioned from the traditional confines of Multi-Party Computation (MPC) to the cutting-edge realm of Account Abstraction (AA). It’s a narrative brimming with challenges, breakthroughs, and a relentless pursuit of progress.

In our quest for a more dynamic and decentralized blockchain experience, we encountered and partnered with two pivotal players: ZeroDev and Pimlico. Their technologies and insights were instrumental in our evolution and reshaping how we interact with the blockchain.

As Frak gears up for the “Village BUIDL on Polygon #1” competition, this story is not just about a tech shift but a stride towards revolutionizing user engagement in the blockchain world. Stay tuned for an insightful exploration of our transition journey, the role of our tech partners, and the impact of AA on our platform.

Here’s a quick roadmap of our discussion:

• The Initial Phase: MPC and Its Boundaries
• The AA Advantage: A New Era for Blockchain
• Partnering with Pimlico and ZeroDev: A Strategic Move
• Frak at “Village BUIDL on Polygon #1”: Showcasing Innovation

Let’s dive into the transformative world of Frak and blockchain technology! 🌐💡

1. The Initial Phase: MPC and Its Boundaries

In Frak’s early blockchain explorations, we chose Multi-Party Computation (MPC) for its security. However, as we grew, we recognized its limitations:

• Centralization Concerns: Despite its security strengths, MPC’s centralized approach didn’t align well with our vision of a decentralized blockchain ecosystem.
• Scalability Issues: As Frak expanded, the inflexibility of MPC in scaling to meet our needs became increasingly clear.

These insights led us to explore other options, and that’s where Account Abstraction (AA) caught our attention:

• Flexibility and Control: AA offered the adaptability and user autonomy that MPC lacked, aligning more closely with our goals.
• Security Plus Innovation: AA wasn’t just secure; it also brought innovative approaches to user interaction and control within the blockchain space.

Our journey with MPC was a critical learning curve. It highlighted our needs and paved the way for the adoption of AA, a technology that promised to keep pace with both our and our users’ evolving requirements.

Up next, let’s take a closer look at AA, exploring how it became a game-changer for us, especially in collaboration with ZeroDev and Pimlico. 🚀🔧

2. AA Demystified: What It Means for Devs

With our sights set on Account Abstraction (AA), we embarked on a path that redefined our approach to blockchain. AA, at its core, is about flexibility and user empowerment, and here’s what it brought to the table for Frak:

• User-Centric Control: AA shifts the control back to the users. It allows for more intricate transaction rules, enabling users to have a say in how their transactions are processed.
• Enhanced Security: By abstracting away from traditional wallet structures and integrating Kernel smart accounts from ZeroDev, AA provides a more secure environment. These smart accounts reduce risks associated with key management by allowing multiple validators and introducing the capability for p256 signers.
• Developer Flexibility: For devs, AA, coupled with Kernel smart accounts, becomes a playground of innovation. It allows for the creation of more complex and efficient smart contracts, offering a wider range of possibilities in contract design.
• Streamlined Interactions: AA simplifies interactions within the blockchain. It enables smoother transaction processes, making the user experience more intuitive and less technical.

Our dive into AA was significantly bolstered by our collaborative efforts with ZeroDev and Pimlico:

• ZeroDev’s Expertise and Kernel Accounts: Their insights helped us navigate the complexities of AA, ensuring that our implementation was both efficient and effective. The Kernel smart accounts from ZeroDev were pivotal in enhancing the security and operational flexibility of our AA implementation.
• Pimlico’s Permissionless.js: This tool was a game-changer, offering us the flexibility and efficiency we needed in our AA implementation.

By integrating AA with Kernel smart accounts, we didn’t just upgrade our technology; we opened up a world of possibilities for both our developers and users. It was a step towards a more inclusive, secure, and innovative blockchain ecosystem.

In the next section, we’ll explore how our partnerships with ZeroDev and Pimlico catalyzed this transformation.

3. Partnering with Pimlico and ZeroDev: A Strategic Move

Our transition to Account Abstraction (AA) was significantly influenced by our partnerships with Pimlico and ZeroDev. These collaborations were pivotal in our successful adoption of AA, offering unparalleled support and invaluable feedback.

ZeroDev Collaboration:

• Integration and Optimization: ZeroDev’s expertise was instrumental in seamlessly integrating AA with our Kernel smart accounts into our system. Their guidance helped us efficiently optimize the transition process.
• Exceptional Developer Support: ZeroDev provided exceptional support, equipping our developers with in-depth insights and effective solutions for implementing AA and maximizing the potential of Kernel smart accounts.

Pimlico’s Permissionless.js and Support:

• Crucial Flexibility and Efficiency: Permissionless.js from Pimlico was crucial for our AA implementation. Its flexibility and efficiency were perfect for our specific needs, especially in integrating with the Kernel smart accounts.
• Outstanding Support and Feedback: Pimlico’s team stood out with their excellent support, rivaling all others we’ve worked with. Their feedback was essential in fine-tuning our approach to AA.
• Active Contribution: Our team actively contributed to enhancing Permissionless.js, ensuring it aligned perfectly with our platform and the Kernel smart accounts.

Collaborating with ZeroDev and Pimlico was about more than just adopting new technology; it was about being part of a community-driven process of innovation. These partnerships allowed us to:

• Exchange Ideas and Strategies: We engaged in a rich exchange of ideas, deepening our understanding of AA, and exploring its potential applications, especially in conjunction with Kernel smart accounts.
• Build a Collaborative Ecosystem: Working closely with these tech leaders enabled us to contribute to the broader blockchain ecosystem, fostering innovation that extends beyond Frak.

Our journey with ZeroDev and Pimlico exemplifies the power of collaboration in technology. It underscores the importance of finding the right partners to navigate new technological terrains and achieve collective success.

Next, let’s explore the specific benefits AA brought to Frak, transforming our platform and user experience in profound ways, especially with the integration of Kernel smart accounts. 🤝🔧🌐

4. The Benefits Unveiled: Why AA Makes Sense for Us

Embracing Account Abstraction (AA) brought a host of benefits to Frak, aligning perfectly with our vision for a more innovative, user-centric blockchain platform. Here’s a breakdown of the key advantages we gained:

• Enhanced User Experience: AA allowed us to create a more intuitive and seamless experience for our users. With more control over transactions and simpler interfaces, user interaction with our platform became smoother and more engaging.
• Increased Security and Trust: The abstraction layer added by AA significantly improved security. By minimizing direct exposure of private keys and enabling more flexible transaction validation rules, we enhanced the overall trustworthiness of our platform.
• Developer Creativity Unleashed: For our developers, AA was a game-changer. It opened up new avenues for creativity in smart contract design, allowing them to innovate beyond the constraints of traditional wallet structures.
• Scalability and Flexibility: AA’s architecture provided us with the scalability and flexibility needed to adapt to future blockchain advancements and user needs. This adaptability is crucial for staying at the forefront of blockchain technology.
• Cost-Effective Operations: Transitioning to AA also meant more cost-effective operations. The efficiency it brought to transaction processing led to reduced costs, making our platform more economical to run.

Our move to AA was a calculated step towards a future where blockchain technology is more accessible, secure, and user-friendly. It was about creating a platform that not only meets the current demands of our users but is also poised to evolve with the ever-changing blockchain landscape.

In our final section, let’s explore how our participation in the “Village BUIDL on Polygon #1” is a showcase of this innovative journey and what it signifies for the future of Frak. 🌟👥

5. Frak at “Village BUIDL on Polygon #1”: Showcasing Innovation

As we prepare for the “Village BUIDL on Polygon #1” competition, our journey with Account Abstraction (AA) and the collaborations with ZeroDev and Pimlico take center stage. This event is more than just a competition for us; it’s a platform to showcase how far we’ve come and where we’re headed. Here’s what our participation signifies:

• Demonstrating Frak’s Innovation: Participating in “Village BUIDL on Polygon #1” gives us the opportunity to display the innovative solutions we’ve developed with AA. It’s a chance to show how we’re redefining user interaction within the blockchain space.
• Highlighting Collaborative Success: This event allows us to highlight the successful collaborations with ZeroDev and Pimlico. It’s a testament to the power of teamwork and shared vision in the tech world.
• Engaging with the Blockchain Community: Being part of “Village BUIDL on Polygon #1” enables us to engage with the broader blockchain community. It’s an opportunity to exchange ideas, gather feedback, and gain new perspectives.
• Setting the Stage for Future Growth: Our presence at this event is not just about what we’ve achieved but also about setting the stage for future growth. It’s a chance to explore new partnerships, opportunities, and innovations.
• Reinforcing Our Commitment to the Polygon Ecosystem: By participating in an event focused on the Polygon ecosystem, we reinforce our commitment to this space and its potential for growth and innovation.

As we step into the “Village BUIDL on Polygon #1” competition, we’re not just showcasing our technological advancements; we’re demonstrating our commitment to continuous innovation and our role as a key player in the blockchain industry. We’re excited to share our journey, learn from others, and continue pushing the boundaries of what’s possible in blockchain technology. 🚀🌐💡

Conclusion: Charting the Future with Account Abstraction

As we reflect on our journey from Multi-Party Computation to Account Abstraction (AA), our participation in the “Village BUIDL on Polygon #1” competition stands as a proud testament to our evolution and innovation in the blockchain space. This journey, enriched by our collaborations with ZeroDev and Pimlico, has transformed our platform and redefined our approach to blockchain technology.

Here’s what we take away from this transformative journey:

• Innovation at the Core: Our transition to AA, especially with the integration of ZeroDev’s Kernel smart accounts, underscores our commitment to innovation, ensuring that Frak stays at the forefront of blockchain technology advancements.
• User-Centric Philosophy: The shift to AA aligns perfectly with our vision of a user-driven blockchain ecosystem. By prioritizing security, control, and an enhanced user experience, we’ve made our platform more intuitive and accessible.
• Collaboration as a Driving Force: Our partnerships with ZeroDev and Pimlico highlight the significance of collaboration in achieving technological breakthroughs. These collaborations were key in successfully navigating new frontiers in the blockchain realm and maximizing the potential of AA.
• Commitment to the Polygon Ecosystem: Our active participation in “Village BUIDL on Polygon #1” reinforces our dedication to the Polygon ecosystem. This event is an opportunity to showcase our contributions, learn from fellow innovators, and demonstrate our integrated solutions featuring AA and Kernel smart accounts.

Looking to the future, we are excited about the endless possibilities that AA opens up for Frak and the broader blockchain community. We’re eager to continue exploring, innovating, and contributing to this ever-evolving landscape. The journey with AA is just the beginning, and we’re enthusiastic about the new horizons it will unveil. Here’s to pushing the boundaries of decentralized technology and shaping the future of blockchain! 🌟🔗🌍

Frak’s Vanguard: Pioneering the Account Abstraction Revolution in the Polygon Ecosystem was originally published in frak-defi on Medium, where people are continuing the conversation by highlighting and responding to this story.

Perfecting ERC-2612: Boost Your DeFi Skills with Solidity Unit Testing in Hardhat and Forge

Hello everyone, and welcome to the third article in our series on ERC-2612! In the previous articles, we’ve discussed the general overview of ERC-2612 and its implementation in Solidity using EIP-712, which enhances user experience and interactions with DeFi platforms like Frak.

Now, it’s time to dive into the essential aspect of ensuring the reliability and security of your smart contracts: unit testing.

In this article, we’ll explore how to create comprehensive unit tests for your ERC-2612 implementation using popular development tools like Hardhat or Forge.

Here’s a recap of our article series:

• Part 1: General overview of ERC-2612 (March 13, 2023)
• Part 2: Solidity development of ERC-2612 (March 23, 2023)
• Part 3: Unit testing with Hardhat or Forge (this article)
• Part 4: Implementation with Ether.js and Fireblocks (coming soon)

By the end of this article, you’ll be familiar with the best practices for unit testing ERC-2612 and EIP-712 implementations, ensuring the robustness and security of your ERC-20 tokens and their integration with DeFi platforms.

So, let’s jump into the world of unit testing!

Prerequisites

Before diving into unit testing with Hardhat and Forge, there are a few prerequisites to ensure a smooth learning experience:

• Solid understanding of Solidity and ERC-2612 implementation: Since this article focuses on unit testing the ERC-2612 and EIP-712 implementation, it’s essential to have a good grasp of Solidity and the concepts covered in the previous articles of this series. If you haven’t already, we highly recommend reading Part 1: General overview of ERC-2612 and Part 2: Solidity development of ERC-2612 before proceeding.
• Familiarity with unit testing in the context of smart contracts: This article assumes that you have basic knowledge of unit testing concepts and experience with either Hardhat or Forge for testing smart contracts. If you’re new to unit testing or need a refresher, consider checking out some introductory resources on Hardhat testing or Forge testing before diving in.
• Required tools and environment setup: To follow along with the examples, make sure you have the necessary tools and environment set up for either Hardhat or Forge.

Now that we’ve covered the prerequisites, we’re ready to delve into unit testing our ERC-2612 and EIP-712 implementation with Hardhat and Forge. Let’s get started!

Disclaimer: In this article, we will primarily focus on successful unit test cases. It is essential to implement unit tests for every error and edge case to ensure the robustness and security of your smart contract. Make sure to thoroughly test all possible scenarios when developing your own contracts.

Unit Testing with Hardhat

In this section, we’ll walk through the process of setting up and executing unit tests for your ERC-2612 and EIP-712 implementation using Hardhat.

Setting up variables for the hash (value, nonce, deadline)

To start, we’ll define the variables necessary for generating the hash, including the value to be approved, the nonce to prevent replay attacks, and the deadline to ensure the approval is time-limited.

Building the domain data, types, and values for the hash

Next, we’ll construct the EIP-712 domain data, types, and values required for hashing and signing the permit function. This step ensures that our hash conforms to the EIP-712 standard.

Signing the hash and extracting the r, s, and v values

With the hash properly constructed, we can now sign it using the private key of the approver. After signing the hash, we’ll extract the r, s, and v values from the signature, which are necessary for calling the permit function.

Calling the permit function, ensuring allowance, and executing a transfer

With the r, s, and v values in hand, we can now call the permit function in our smart contract. After calling the permit function, we’ll check the allowance to verify that the approval has been successfully recorded.

Then, with the approval in place, we can then call the transfer function on behalf of the approver. We’ll verify that the transfer was successful by checking the updated token balances.

By combining these steps, we efficiently test the permit and transfer functions together, ensuring a seamless approval and transfer process in our ERC-2612 and EIP-712 implementation using Hardhat. This approach helps verify the proper functioning of your smart contracts and enhances their overall security and reliability.

Unit Testing with Forge

In this section, we’ll walk through the process of setting up and executing unit tests for your ERC-2612 and EIP-712 implementation using Forge.

Set up variables for the hash (value, nonce, deadline)

Just like with Hardhat, we’ll start by setting up the variables needed for the EIP-712 hash. You’ll need to define the value, nonce, and deadline:

Build the domain data, types, and values for the hash

Next, build the domain data, types, and values required for the EIP-712 hash. This process remains the same as in the Hardhat example:

Sign the hash and extract the r, s, and v values

To sign the hash using Forge, you can use the vm.sign(). Extract the r, s, and v values as shown below:

Call the permit and ensure allowance, then execute the transfer and ensure its success

Finally, call the permit function, check the allowance, and execute the transfer using the Forge testing framework. The code snippet is the same as in the Hardhat example:

By following these steps, you can successfully implement unit testing for your ERC-2612 and EIP-712 implementation using Forge.

Comparing Hardhat and Forge

When it comes to unit testing smart contracts, Hardhat and Forge are both popular choices. However, there are some notable differences between the two that can impact your development experience. In this section, we’ll compare the two frameworks, highlighting their strengths and weaknesses.

Code Complexity and Readability

In my opinion, Hardhat’s testing syntax is more complex and less readable compared to Forge.

Hardhat relies on JavaScript for writing tests, whereas Forge allows you to write tests directly in Solidity. As a result, Forge tests tend to be cleaner and more focused on the Solidity code itself, making it easier to reason about the contract logic.

Performance

Forge has a clear advantage when it comes to test execution speed. In our experience, Hardhat tests took 40ms to run, while Forge tests were significantly faster, taking only 9.03ms.

This difference can be crucial when working on large projects with many tests, where faster test execution can save valuable time.

Flexibility and Ease of Use

Forge’s Solidity-based testing approach makes it much easier to test all edge cases, ensuring comprehensive coverage of your smart contracts.

This is because you can leverage the full power of Solidity when writing your tests, keeping your repository solely focused on the language you’re working with.

Advanced Testing Capabilities

Forge offers some advanced testing features that can enhance the security of your smart contracts.

With Forge, you can easily perform fuzz testing, invariant testing, and even test your contracts against mainnet data using the Cast feature.

These advanced testing capabilities can help you uncover hidden vulnerabilities and ensure the robustness of your smart contracts.

In conclusion, both Hardhat and Forge are powerful unit testing frameworks with their own strengths and weaknesses. While Hardhat may be more familiar to some developers, Forge offers a clean, Solidity-centric approach to testing, along with advanced testing features that can significantly improve the security of your smart contracts. Ultimately, the choice between the two will depend on your personal preferences and requirements.

Conclusion

Congratulations on completing the third instalment of our series on ERC-2612! You’ve gained valuable insights into unit testing with Hardhat and Forge, and now understand their differences, strengths, and weaknesses. By choosing the right testing framework for your needs, you can ensure the robustness and security of your ERC-20 tokens and DeFi protocols.

But we’re not done yet! The final article in this series will cover the implementation of ERC-2612 using Ether.js and Fireblocks, demonstrating how to make your smart contracts even more powerful and accessible.

If you found this article helpful, please give it a clap, share it, and follow me for more in-depth articles on Solidity, DeFi, and the blockchain world.

Are you ready to take the next step? Let’s continue our journey into the world of DeFi together!

ERC-2612: The Ultimate Guide to Gasless ERC-20 Approvals — part 3 was originally published in frak-defi on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Frak Protocol is an innovative DeFi platform designed to align creators’ interests with their communities. It empowers users to invest in content-linked assets and benefit from their favorite content’s growth, while creators maintain control over their IPs. If you’re excited to join the Frak community, this step-by-step guide will walk you through the seamless onboarding process.

Step 1: Download the Chrome Extension

To get started, you’ll need to download the Frak Chrome extension. Visit the Frak page on the Chrome Web Store then click “Add to Chrome” and confirm the installation. The Frak Protocol icon will now appear in your browser’s extension bar.

Don’t forget to pin the extension to follow your rewards in real time.
At this step, the icon is grey.

Step 2: Sign Up for an Account

Click on the Frak icon in your browser’s extension bar to open the sign up screen in the dashboard space. You’ll be prompted to sign up for an account. Provide your email address and create a strong password.

You must now enter the code you’ve just received in your mailbox.

Once you’ve successfully signed up, you’re ready to experience the power of the Frak Protocol. You can notice that the extension icon is now colored with the beautiful Frak gradient. 🤗

You can expand the extension quickly with the following shortcut :

• Alt + Maj + F (Windows)
• Option + Maj + F (Mac)

Step 3: Watch a first Video on YouTube to create your wallet

Head over to YouTube and find a video from one of the +20k Youtube channels already registered in the Frak Protocol. To create your own wallet in the Frak Protocol and start being rewarded, you’ll need to watch this video for at least 1 minute (this allows the platform to avoid bots) and until the end of the video.

You can now see that the Frak icon is green 🟢

For more convenience, we advise you to watch directly the video presentation of Frak. In addition, you will have a global overview of the protocol !

Step 4: Let the Extension Create Your Wallet

Once the video is completed, The Frak Protocol Chrome extension will automatically create a wallet for you. You can also navigate away from the YouTube page to trigger the wallet creation. You can find now your wallet address in the header of the extension (just click on it if you need to copy it).

This wallet will store your Frak assets, including any content-linked investments (Fraktions) and rewards you earn (FRK token).

Congratulations! You are now a part of the Frak Protocol community. You can start being rewarded by watching Youtube videos, investing in your favorite content, and enjoying a more equitable, transparent, and community-driven content ecosystem.

Conclusion:

The Frak Protocol’s onboarding process is designed to be user-friendly and efficient. By following these simple steps, you can quickly become a part of the Frak community and enjoy the benefits of a platform that empowers creators, users, and advertisers alike. Install the Frak Protocol Chrome extension and start investing in the content you love today!

Please feel free to share any comments about this onboarding in order to help us to improve the protocol!

If you want to continue the conversation, you can connect with me @MViala on Twitter or on Telegram.
Be informed when a new article is published by following us on Medium. If you liked this article, please clap for it (up to 50x) to let us know you enjoyed it. It’ll mean a lot to us. Thank you !

A Step-by-Step Guide to Onboarding with the Frak Protocol was originally published in frak-defi on Medium, where people are continuing the conversation by highlighting and responding to this story.

Revert with finesse: Maximize your gas savings with this simple trick!

Hi there, fellow DeFi enthusiasts! Buckle up for another exciting article that will have you rethinking your Solidity code for maximum gas efficiency.

This time, we’ll explore the fascinating world of revert with error messages and dive into the specifics of why it’s better to use revert with error instead of revert with a string.

My experience at Frak, a DeFi protocol, has given me a front-row seat to the challenges and opportunities that come with optimizing smart contracts for efficiency.

So, what’s in store for you? We’ll take a closer look at revert with error in assembly, and even discuss the low EVM implication, contract size implication, and why it’s more efficient even if the transaction doesn’t revert. And, of course, we’ll provide you with some juicy code snippets to compare and contrast the different techniques.

Ready to make your smart contracts leaner and meaner? Let’s dive in!

Revert with String

In the early days of Solidity, developers used the revert function with a string parameter to handle errors. This provided a human-readable error message when things went haywire. Feast your eyes on this code snippet of a simple function that reverts with a string:

As nifty as descriptive error messages can be, this method is a gas glutton. But fear not, for there is a better way!

Revert with Error

Enter Solidity 0.8.4, armed with custom errors and a thirst for gas efficiency.

By opting for revert with an error instead of a string, we can keep the advantages of expressive error messages without draining our gas reserves. Check out the same function as before, but now with a revert error:

Revert with Error in assembly

Finally, we have the king of gas efficiency, revert with an error code in assembly. This method is the most gas-efficient, but it’s also the most complex. Use it wisely!

Why the Gas Differences?

Now that we’ve seen the magic tricks, let’s dive into the “why.” There are three primary reasons for the gas differences between the three methods:

1. Low EVM Implication: When you revert with a string, the EVM has to store the string in memory, which consumes more gas than simply using an error code. In contrast, error codes are more efficient for the EVM, resulting in lower gas consumption.
2. Contract Size Implication: Contracts with larger strings take up more space on the Ethereum blockchain, resulting in a larger contract size. A larger contract size means more gas is consumed for deployment and execution. Using error codes instead of strings keeps your contract size smaller and more efficient.
3. Efficiency Even Without Revert: Even if your transaction doesn’t revert, using error codes over strings is still more efficient. The EVM has to parse the error string, regardless of whether the transaction reverts or not. By using error codes, you’re saving gas on every transaction!

Benchmark Comparison

To showcase the gas efficiency of revert with error over revert with string, let’s examine a benchmark comparison of the three code snippets:

In this benchmark, you can clearly see the differences in contract size and gas consumption between the three methods. The gas savings are substantial, especially when using revert with an error in assembly.

You can find the snippet and the gas usage test here, test done with foundry.

Conclusion

Kudos! You’ve now unlocked the secret to optimizing gas efficiency in Solidity by choosing revert with error over revert with string. Small changes like these can have a significant impact on your DeFi protocols, just like we did at Frak.

If this article fueled your passion for gas efficiency, don’t hesitate to give it a clap, share it, and follow me for more witty and engaging articles on Solidity and the DeFi universe.

Our journey into the world of DeFi is far from over! Stay tuned, and together, we’ll continue to explore the fascinating realm of decentralized finance. Let the adventure continue!

Solidity Gas Efficiency Unleashed: Revert with Error vs Revert with String — A Deep Dive was originally published in frak-defi on Medium, where people are continuing the conversation by highlighting and responding to this story.

A deep dive into the Solidity code of gasless ERC-20 approvals ERC-2612

Hi everyone, welcome back to the second article of my series on ERC-2612! If you missed the first article, we covered the general overview of ERC-2612, an ERC-20 token extension that leverages EIP-712 signatures for approving spenders.

This ingenious combination simplifies and streamlines user interactions with DeFi platforms, like the one I worked on at Frak.

Today, we’re diving into the nitty-gritty of implementing ERC-2612 in Solidity while incorporating EIP-712. We’ll explore the domain separator, the Permit type, the permit function, and the implementation intricacies, such as nonce management and deadlines.

Here’s a breakdown of the article series:

1. Part 1: General overview of ERC-2612 (March 13, 2023)
2. Part 2: Solidity development of ERC-2612 (this article)
3. Part 3: Unit testing with Hardhat or Forge (coming soon)
4. Part 4: Implementation with Ether.js and Fireblocks (coming soon)

By the end of this article, you’ll be well-equipped to implement ERC-2612 and EIP-712 in Solidity and fully leverage their benefits for your own ERC-20 tokens, enhancing user experience, flexibility, and integration with other DeFi protocols.

So let’s dive in!

1. Adding EIP-712 Support

To implement EIP-712 in our existing ERC-20 token contract, we’ll first define the required domain separator type hashes.

You can add a “bytes32 salt” at the end of the domain typehash, if you’re protocol contain multiple implementation.

The chainId is optional, we use it at Frak since we are planning on bridging our FrkToken to multiple chain.

Next, we need to store the domain separator itself:

Initialize the DOMAIN_SEPARATOR in the constructor of your ERC-20 token contract, by calling a function similar to this one (github):

The getChainId() method is just a simple helper function that return the current chainId. If you are using solidity 0.8+ you can simply use block.chainid.

2. Adding ERC-2612 Support

Now, let’s add support for ERC-2612 by creating the Permit type hash and adding the nonces mapping:

Next, implement the permit function (github):

The permit function constructs the EIP-712 typed data structure, hashes it, and verifies the signer's address using the ecrecover function. If the signature is valid and the deadline has not expired, it calls the internal _approve function to update the allowance mapping.

For the error, we are using assembly and error to be more gas efficient (less memory used and no need to send a string)

Here we are using a small helper function toTypedMessageHash() , that help us create EIP-712 typed data hashes (github).

We are using assembly here to be more gas efficient.

With these changes in place, your ERC-20 token contract now supports both ERC-2612 and EIP-712. Users can approve spenders via signatures instead of transactions, making interactions with your token contract more efficient and user-friendly.

3. Some pitfalls of implementation

3.1 Deadlines and Time Synchronization

When implementing the permit function, it's essential to manage deadlines effectively. Using block.timestamp for deadline comparisons can help prevent attacks related to manipulating block time. However, it's worth noting that the block.timestamp value is determined by miners and can be off by a few seconds, so take this into account when setting deadlines for permit signatures.

3.2 Signature Security

Always be cautious about the security aspects of signature handling. For example, ensure that your implementation properly validates the recovered address to avoid potential vulnerabilities. Additionally, be aware that the ecrecover function returns the zero address if the signature is invalid, so always check for this scenario in your implementation.

3.3 Gas Costs

While using signatures for approvals can reduce gas costs for users, the actual permit function itself might be gas-intensive due to the cryptographic operations involved, such as keccak256 and ecrecover. It's crucial to analyze and optimize gas costs during the development process to ensure that your implementation remains efficient and cost-effective.

3.4 Chain ID Changes

The EIP-712 domain separator includes the chain ID to prevent replay attacks across different networks. However, it’s essential to remember that the chain ID can change in certain situations, such as during a network upgrade or a hard fork. When this occurs, the domain separator must be updated accordingly. One solution is to implement a function that allows the contract owner to update the domain separator when a chain ID change occurs.

3.5 Debugging Signature Issues

During the implementation process, you may encounter issues related to signature verification. Debugging these issues can be challenging, as cryptographic functions tend to be less intuitive and harder to trace. To help overcome this pain point, it’s crucial to become familiar with the EIP-712 specification, understand the expected input format for the ecrecover function, and use test cases to verify the correctness of your signature generation and verification code.

From my personal experience, I highly recommend setting up Foundry unit tests and emitting numerous events at each step of the process to confirm the accuracy of your implementation. Utilizing a Foundry test case with a high verbosity output (e.g., -vvvv) will allow you to monitor all events, making it much easier to identify and resolve potential issues that may arise.

By keeping these potential pitfalls in mind, you can ensure a robust and secure implementation of ERC-2612 and EIP-712 in your ERC-20 token contract.

Conclusion

Congratulations! You’ve now unlocked the full potential of ERC-2612 and EIP-712 in Solidity. By combining these standards, your ERC-20 tokens will enjoy improved user experience and seamless integration with the ever-evolving DeFi ecosystem.

But don’t stop here! Keep an eye out for the next articles in this series, where we’ll cover unit testing with Hardhat or Forge and implementing ERC-2612 using Ether.js and Fireblocks. If you found this article helpful, please give it a clap, share it, and follow me for more insightful articles on Solidity and the DeFi world.

Ready for the next adventure? Let’s continue our journey into the world of DeFi together!

ERC-2612: The Ultimate Guide to Gasless ERC-20 Approvals — part 2 was originally published in frak-defi on Medium, where people are continuing the conversation by highlighting and responding to this story.

How to use EIP-712 signatures to save gas, batch approvals and increase security for your ERC-20 tokens.

If you are a developer or a user of ERC-20 tokens, you probably know how annoying and costly it is to approve a spender contract before it can transfer tokens on your behalf. You have to send a transaction, pay gas fees, wait for confirmation and hope that nothing goes wrong.

But what if I told you that there is a better way to do approvals? A way that is faster, cheaper, safer and more user-friendly? A way that uses EIP-712 signatures instead of transactions?

I’ve discovered that ERC-2612 was the solution to those issues. It’s an extension for ERC-20 tokens that allows users to approve spenders via EIP-712 signatures instead of transactions. EIP-712 is a standard for hashing and signing typed structured data as opposed to just bytestrings.

In this article, I will explain what is ERC-2612 and how it can improve the user experience and security of ERC-20 approvals. I will also show you how to implement it in Solidity contracts and how to test it with Hardhat or Foundry. Finally, I will demonstrate how to use it with Ether.js and Fireblocks libraries.

By implementing ERC-2612 at Frak, we makes it easier and cheaper for users to interact with our platform and other DeFi protocols.

This will be a series of articles divided into four parts:

• Part 1: General overview of ERC-2612 (March 13, 2023)
• Part 2: Solidity development of ERC-2612
• Part 3: Unit testing with Hardhat or Forge
• Part 4: Implementation with Ether.js and Fireblocks

By the end of this series, you will be able to use ERC-2612 for your own ERC-20 tokens or interact with existing ones that support it. You will also learn how Frak leverages ERC-2612 to enable gasless token transfers and frictionless DeFi interactions.

Let’s get started!

How does ERC-2612 work?

ERC-2612 introduces a new function called permit that takes an EIP-712 signature as an input and updates the allowance mapping accordingly. The signature must contain the following fields:

• owner: The address of the token owner who signed the message
• spender: The address of the spender contract who can transfer tokens on behalf of the owner
• value: The maximum amount of tokens that can be transferred by the spender
• nonce: A unique number that prevents replay attacks
• deadline: A timestamp after which the signature is invalid
• v, r, s: The components of the EIP-712 signature that proves the owner’s consent

The signature must follow a specific format defined by EIP-712. It must include a domain separator and a type hash that identify the token contract and the permit function. It must also encode and hash the parameters according to a specific schema.

In our case, the parameter for the signature are the following:

The token contract then verifies that the signature is valid and matches the parameters. If so, it updates the allowance mapping accordingly.

This means that the token contract performs two checks before updating the allowance mapping:

1. It checks that the signature is valid. This involves hashing the parameters using EIP-712 and recovering the signer’s address from the signature using ‘ecrecover’. Then it compares the recovered address with the owner address provided in the parameters. If they match, it means that the owner has signed the message and consented to approve the spender. Otherwise, it means that someone else has forged or tampered with the signature and it should be rejected.
2. It checks that the parameters are valid. This involves checking that the deadline has not expired, that the value is not greater than the owner’s balance, and that the nonce is the current one for the owner (to prevent replay attack’s). If these conditions are met, it means that the approval is still valid and can be executed. Otherwise, it means that something has changed since the owner signed the message and it should be rejected.

If both checks pass, then it means that everything is in order and there is no reason to deny or delay the approval. Therefore, it updates the allowance mapping.

This allows the spender to transfer up to value tokens on behalf of owner.

This way, the owner does not have to send a transaction to approve the spender. They can sign a message offline and send it to anyone who can submit it to the token contract. They can also revoke or change their approval at any time by signing a new message with a different value.

ERC-2612 has been adopted by many popular ERC-20 tokens, such as DAI, UNI, COMP etc. It has also been integrated with many DeFi protocols and platforms, such as Uniswap, Compound, Aave, Frak etc. It has become a de facto standard for gasless ERC-20 approvals and transfers.

What are the benefits of ERC-2612?

In my experience, using EIP-712 signatures for approvals has several advantages over using transactions.

• Gas savings: Users don’t have to send any transactions or pay any gas fees to approve spenders. They can simply sign a message with their private key and send it to the spender contract or a third-party service that can relay it to the contract.
• Batching: Users can approve multiple spenders with one signature by using different nonces or values. This reduces friction and complexity for users who want to interact with multiple contracts or services. In my experience with Frak, where we have custodial wallets and pay for a lot of user gas fees, batching has been particularly important.
• Security: Users can include additional parameters such as expiry time or maximum amount in their signatures. This gives them more control and flexibility over their approvals and prevents replay attacks or unlimited spending.

Pain points of implementing ERC-2612

While ERC-2612 offers many benefits for ERC-20 approvals, it also comes with some challenges and trade-offs that you should be aware of before implementing it.

One of the main pain points is the complexity of EIP-712 signatures. EIP-712 is a standard for hashing and signing typed structured data as opposed to just bytestrings. This means that you have to define a domain separator and a type hash for your permit function, as well as encode and hash the parameters according to a specific format.

This can be tricky and error-prone, especially if you are not familiar with EIP-712 or low-level Solidity operations. Fortunately, there are some libraries and tools that can help you with this task, such as OpenZeppelin contracts, Hardhat EIP-712 plugin, Ether.js utils, Fireblocks SDK, etc.

Another challenge I have encountered is ensuring compatibility with different wallets and providers. Not all wallets support EIP-712 signatures natively which may require workarounds or fallbacks to make your permit function work with them. For example, some wallets may require a signature prefix (such as “\x19Ethereum Signed Message:\n32”) or a different chain id than expected. (I’ve lost a day or two with this !)

You also have to consider how your users will sign their permits. Will they use MetaMask, WalletConnect, Ledger, Trezor, etc.? Will they sign on-chain or off-chain? Will they sign using their private key or a smart contract (such as EIP-1271 )? These factors may affect how you implement and test your permit function.

Finally, you have to be careful about security issues and edge cases when using permits. For instance, you have to prevent replay attacks by using nonces and validating chain ids . You also have to handle expiration dates and invalid signatures gracefully. You may also want to add some extra checks or events for debugging purposes.

As you can see, implementing ERC-2612 is not trivial and requires some attention to detail.

However, once you get it right, you will enjoy the benefits of gasless ERC-20 approvals for yourself and your users. Stay tuned for the second part of this article series where I will cover the Solidity implementation of ERC 2612.

I hope this article has provided valuable insights into its benefits and challenges. If you found it helpful, please don’t hesitate to follow me and give this article a clap.

ERC-2612: The Ultimate Guide to Gasless ERC-20 Approvals was originally published in frak-defi on Medium, where people are continuing the conversation by highlighting and responding to this story.

As the head of smart contract at Frak, a web3 company that is working to create a new revenue model for content creators and users using blockchain technology, I know firsthand the importance of ensuring the quality and reliability of our code.

One of the key tools we use to achieve this is unit testing, which allows us to validate the behavior of individual units of code and catch any issues early on in the development process.

In this article, I’ll be sharing our experience with switching from Hardhat to Foundry for unit testing in Solidity. By sharing our journey, I hope to provide valuable insights and guidance for other Solidity developers who are considering a similar switch.

Hardhat vs Foundry

I won’t go into details here about what Hardhat and Foundry are, but briefly, Hardhat is the most widely used framework for Solidity development, deployment, and testing, mainly using JavaScript to perform all of these tasks, while Foundry is a new framework, written in Rust, that performs the same tasks but using Solidity code for everything.

Under the hood, Hardhat deploys a local blockchain and uses ether.js to communicate with the contract and Mocha for unit testing, while Foundry uses Forge and Anvil (a local blockchain) to deploy the Solidity test contract, run the tests, and interpret the results.

You can already see where we are going with this. On one hand, a JavaScript script will talk to our local chain for each one of our tests, possibly making multiple calls to the local chain, on the other hand, the test contract is completely deployed on a local chain, and a script will only execute the test methods.

Benchmark

I will run benchmarks on our FrakTreasuryWallet contract. It’s a really simple contract (upgradeable and with roles) but it only has one method to perform a transfer from our treasury to a given address.

A test is quite interesting on this contract, since we need to ensure that we won’t exceed the amount planned for our treasury (in our case, 330 million tokens), but the contract only mints tokens in chunks of 1 million. So, we need to call the contract a tremendous number of times to perform all the transfers and empty the contract, and to make sure that no more transfers can be made from an empty treasury.

Here are the results of the unit tests, using both Hardhat and Forge.

You can see that Hardhat took 13 seconds to execute all the tests, and almost 9 seconds for the test where we need to empty the treasury. Meanwhile, Forge only took 102 milliseconds to perform the same thing.

And with Forge, we also got a fuzzed test that has run 256 times (which is not currently possible with Hardhat), so it ran 256 more executions of our contract, over 100 times faster. This provides a much better gas estimation and a lot more reliability since we have random input values.

Benefits

Since the tests are written in Solidity, we can also use inheritance to have some test helpers, and some generic tests (for the upgradeability, roles management, or pause system). In our case, we use it to deploy our contract under a UUPS proxy, with some modifiers to ‘prank’ the address in use for the tests to be the deployer (you can find it here).

The reason for the switch is quite obvious now, it allows us to test our code much faster, perform some gas optimization tests and see the impact on the whole ecosystem in less than a second (post compilation, so around 5 seconds in our case).

Caveat

Since Foundry is purely Solidity-based (for deployment scripts and tests), it required us to rewrite all of our unit tests in the Solidity form. Nonetheless, it allows us to incorporate some fuzzing tests for all of our contracts, giving us better gas estimation for their execution.

We also needed to do some research around the testing framework (for the upgrade part, the assertions, log fetching and accessing some data returned by our functions, etc.) to understand how it works, especially the various “cheat codes” available. But, if you are familiar with Solidity, the learning curve is relatively quick.

If you’re not familiar with “cheat codes”, they help you manipulate the VM in some ways (change the current execution address, fetch logs emitted by an event), I will cover that in more detail in an article about how we set up Foundry for all of our unit tests.

We decided to go with PRBTest instead of the original Foundry test library, since it provides versioning and more assertions, while remaining compatible with all the original VM cheat codes provided by Foundry.

Conclusion

In about a week, we managed to set up Foundry and migrate the majority of our unit tests to it. We encountered a few things that were not well-documented, but they remained easily solvable.

Since the tests ran approximately 100 times faster, it helped us a lot with our research on gas optimization, and it will help us in the future to add new features to our system, test them, and optimize our code even further.

Stay tuned for another article where I will explain how we set up Foundry in our existing Hardhat project and how we set up base unit tests for our upgradeable contract!

In the meantime, you can check out our github repository :)

If you want to continue the conversation, you can connect with us @frak_defi on Twitter or on Telegram.
Be informed when a new article is published by following us on Medium. If you liked this article, please consider giving it a “clap” (up to 50x) to let us know you enjoyed it. It’ll mean a lot to us.

Thank you :)

Maximizing Quality and Reliability in Solidity: Our Journey from Hardhat to Foundry was originally published in frak-defi on Medium, where people are continuing the conversation by highlighting and responding to this story.