Stories by Manny on Medium

Single Transaction Batch Multiswap to BERA with MetaMask Smart Accounts

Manny — Wed, 17 Jun 2026 15:44:54 GMT

Leverage EIP-5792 To Batch Dust Tokens Into BERA

Batch Multiswap Dust Tokens For BERA

The Problem With Multi-Token Swaps Today

If you’ve spent any time in the Berachain ecosystem, your wallet accumulates fast. Incentive tokens, LP rewards, airdrop claims, protocol emissions and before long you’re sitting on a dozen different tokens, each worth a modest amount individually but collectively significant. Converting them all to BERA the traditional way means opening your wallet and signing a separate transaction for every single token: approve, confirm, wait, approve again, confirm again, wait again. For five tokens that’s potentially ten MetaMask popups and ten on-chain transactions.

This is both tedious and expensive. Every transaction costs gas, every confirmation takes time, and the cognitive overhead of managing the flow manually introduces real risk of mistakes. Miss a step, have gas spike mid-flow, or close your browser at the wrong moment and you’re left with a half-completed swap and tokens stuck in limbo.

EIP-5792 (wallet_sendCalls) solves this by giving applications a standardized way to submit an array of calls as a single wallet interaction. The user sees one MetaMask prompt, signs once, and all swaps execute atomically in a single on-chain transaction. If any individual swap fails, the entire batch reverts with no partial state, no cleanup required.

Why Batching Dust Into BERA (Then swBERA) Makes Sense

Berachain’s Proof of Liquidity model means the ecosystem generates a lot of peripheral tokens: BGT emissions and protocol incentive tokens. These accumulate as “dust” that are not worthless, but inconvenient to manage individually.

BERA is the natural consolidation target. It’s the native gas token, it’s universally liquid, and critically it’s the input token for swBERA (staked BERA, Berachain’s liquid staking derivative that earns validator rewards). Converting your scattered dust tokens to BERA via a single batched transaction, then depositing into swBERA, gets you from a fragmented wallet to a productive yield-bearing position in just two user interactions instead of potentially twenty or more.

The compounding benefit is time. Swap five tokens individually at 15 seconds of attention each plus 30 seconds of block confirmation per swap and you’re spending over four minutes on rote mechanical work. Batched, the same outcome takes under 30 seconds of active time and that gap only grows as your token count increases.

Batch swap dusk tokens to BERA

Why Not Alternative Batching Options

Before landing on EIP-5792, it’s worth understanding why the other batching approaches each fall short for this specific use case.

Batching Methods Comparison

Multicall3 is the most universally deployed batching contract on EVM chains and can aggregate multiple calls into one transaction. The critical flaw: msg.sender inside the Multicall3 execution context is the Multicall3 contract itself, not the user. Every major DEX router and aggregator checks msg.sender for token custody and swap authorization. Routing through Multicall3 breaks these checks entirely, causing every swap call to revert.

Permit2 solves a real problem of replacing gas-costing approve() transactions with gasless off-chain signatures, but unfortunatley it doesn’t batch the swaps themselves. It’s an approval mechanism, not an execution mechanism. You still end up with one swap transaction per token. Permit2 is genuinely useful as a complement to EIP-5792 (it can eliminate the approve calls inside your batch), but it cannot replace the batching layer on its own.

ERC-4337 is the infrastructure layer that actually powers smart account batching under the hood and it’s what runs beneath EIP-5792 when MetaMask executes your batch. Integrating directly with ERC-4337 means managing UserOperation construction, bundler connections, EntryPoint interactions, and Paymaster configuration from scratch. It’s powerful but exposes significant plumbing that EIP-5792 correctly abstracts away. EIP-5792 is the right interface for application developers; ERC-4337 is an implementation detail the wallet handles for you. Not to mention that this requires quite a bit of infrastructure set up or relying on third-parties.

EIP-7702 (included in Ethereum’s Pectra upgrade) lets a standard EOA temporarily adopt smart account behaviour for the duration of a single transaction without requiring a full migration. For this use case today the limiting factor is wallet support: EIP-7702 is very new and not yet implemented in production MetaMask builds. It’s the most promising path for eventually bringing batching to all EOA users without requiring a smart account upgrade, but it’s not something you can depend on in production yet due to there lacking proper audited contract code to offer guardrails.

EIP-5792 hits the correct abstraction level for application developers. You describe what you want (an array of calls) the wallet handles how to execute it, and you get a standardized interface that will keep working as the underlying execution mechanism evolves. wallet_getCapabilities lets you detect support gracefully and degrade for unsupported wallets, and wallet_getCallsStatus gives you a clean polling interface for tracking the batch result. It’s the right tool for batching.

Enabling MetaMask Smart Accounts

EIP-5792 batch execution requires a MetaMask smart account rather than a standard EOA. Here’s how to enable it:

Step 1— Navigate to Accounts in the top left of the wallet UI.

Step 2 — Select the 3 Dots > Account Details for the wallet wanting to upgrade.

Step 3 — Enable Smart Account by clicking Set Up.

Step 4 —Toggle On Smart Account for the network desired.

Step 5 — Verify the Upgrade Once upgraded, your account address remains the same but now has contract code deployed at it. You can verify by checking your address on Berascan where it should show as a contract rather than a plain EOA.

Developing or testing early? Use MetaMask Flask for the developer-focused MetaMask build that includes experimental features, including full EIP-5792 support, before they ship in the stable release.

The Prompt For The Project

To see the full PLAN.md for the project take a look here:

guides/apps/batch-multiswap/PLAN.md at main · berachain/guides

Batch Transaction Demo

Here is a full demo of the entire project:

https://medium.com/media/84b2d69672faab6f02a530a182446135/href

Full GitHub Code

If you’d like to try the code out yourself, take a look at:

guides/apps/batch-multiswap at main · berachain/guides

Next Steps

The source code for this project is a foundation, not a finished product. Several directions are worth exploring depending on your goals.

swBERA Auto-Compound — After the batch swap confirms and BERA lands in the user’s wallet, automatically trigger a deposit into the swBERA contract as a follow-on transaction. The full dust-to-yield flow becomes a single user decision rather than two separate ones.

Dynamic Token Discovery — Rather than a static list of known Berachain tokens, integrate with a token indexer such as Covalent or Alchemy to surface every non-zero ERC-20 balance the user holds, including obscure incentive tokens and newly launched assets that wouldn’t appear in a hardcoded list.

EIP-7702 Fallback — Add a fallback path for when a MetaMask smart account isn’t available. As EIP-7702 wallet support matures, users with plain EOAs will be able to access the same batched flow without upgrading their account type. Detecting capability via wallet_getCapabilities already sets you up to route users to the right path when that support lands.

Slippage and Route Optimization — The current implementation applies a flat slippage tolerance across all swaps. A smarter approach would apply per-token slippage based on liquidity depth from the KyberSwap route response and warn users when any individual swap in the batch carries outsized price impact before they confirm.

Multi-Aggregator Routing — Query multiple aggregators such as KyberSwap, OogaBooga, and Li.Fi in parallel per token and select the best rate for each. Since the calldatas are just bytes to the batch executor, mixing aggregators across the same batch is entirely viable and can meaningfully improve total BERA received.

Transaction History — Persist batch IDs and their outcomes to local storage so users can review past batch swaps, see which tokens were included, and verify the final BERA received per swap after the fact.

If you want to build more on Berachain and see more examples. Take a look at our Berachain GitHub Guides Repo for a wide variety of implementations that include NextJS, Hardhat, Viem, Foundry, and more.

❤️ Don’t forget to show some love for this article 👏🏼.

Building A Mobile EVM Wallet With React Native

Manny — Thu, 11 Jun 2026 18:25:58 GMT

Understanding The Tech Behind Building A Mobile Blockchain Application

Building An iOS Mobile Wallet with React Native

The goal of this article isn’t to go through step-by-step building the application (you can do that with AI), but more so understanding the tech needed to build a mobile iOS app for an EVM wallet so that it can help you build one in the future.

EVM iOS Wallet

For the sake of this article, we’ll be focusing specifically on iOS to understand its features, limitations and work arounds.

The functionality we’ll limit ourselves to are:

1 — Setup and manage a new wallet with a passphrase

2 — Backup the passphrase

3 — Add an RPC

4 — Retrieve Balance

5 — Transfer Transaction

Why React Native & Expo

React Native & Expo

React Native lets you write your UI once in JavaScript and ship to both iOS and Android. When it comes to a wallet app, the real selling point is the update model. Native Swift apps must go through Apple’s review process for every change, which can take days. React Native (especially with Expo’s over-the-air updates via EAS Update) lets you push JS-layer fixes instantly, without a new App Store submission. For a wallet, where a bug could mean lost funds, that matters enormously.

Expo specifically adds a lot out of the box: expo-secure-store for Keychain access, expo-local-authentication for biometrics, and a managed build pipeline (EAS Build) that handles the notoriously painful iOS signing and provisioning certificates. You get a familiar React development experience instead of learning Swift and UIKit from scratch.

The tradeoff can be rough though. React Native has a reputation for being finicky. Native modules occasionally break between Expo SDK versions, the Metro bundler has its quirks, and you’ll hit moments where something works on Android but not iOS or vice versa. The bridge between JS and native code also adds a thin layer of complexity when you’re doing security-sensitive work.

Factoring this all in, most production mobile wallets have made exactly this bet. Rainbow Wallet and Coinbase Wallet SDK are all built on React Native.

What’s Not So Simple

Features 1, 3, and 4 are straight forward in terms of their functionality when prompting most LLMs. Backing up a passphrase and interacting with it correctly is the complicated part. Correctly in this case is securely, or as secure as possible.

iCloud Backup & Keychain

The naive approach to backing up a seed phrase seems simple: save it to iCloud or store it in the iOS Keychain, and retrieve it when needed. The problem is how you retrieve it; it’s in plain text.

iCloud Drive storage is essentially a synced filesystem. A file containing your 12-word mnemonic would sit on Apple’s servers, sync to every signed-in device, and be readable by your app (and anything that can compromise your app) as a raw string. That’s not a backup strategy; it’s a liability.

The iOS Keychain is better. It’s encrypted storage tied to your app’s bundle identifier, sandboxed from other apps, and persistent across reinstalls. You can gate items with kSecAttrAccessible flags like WhenUnlockedThisDeviceOnly to prevent the item from being included in unencrypted backups or read on other devices. You can even add kSecAccessControl with a biometric requirement so that reading the item triggers a Face ID prompt.

There’s still a fundamental ceiling here. When your app reads a Keychain item, the raw bytes surface in app memory. At that moment, a compromised JavaScript bundle, a malicious dependency in your node_modules, or a memory-inspection attack could exfiltrate the mnemonic. While Keychain is a good base, it’s ultimately not the final solution itself.

Apple On-Device Secure Enclave

Apple Secure Enclave (SE)

Apple’s answer to the memory-exposure problem is the Secure Enclave (SE), which is a dedicated security coprocessor built into every iPhone since the 5s, isolated from the main application processor.

The key design principle: private keys generated inside the SE never leave it. Your application never holds the private key in memory. Instead, you send data to the SE, the SE performs the cryptographic operation (signing, decryption), and returns only the result. Even if your app, the OS, or the entire file system is compromised, the SE’s keys remain inaccessible.

Secure Enclave Sequence Diagram

The SE has its own encrypted memory, a hardware random number generator, and runs its own microkernel. When you require biometric authentication to use an SE key, the biometric check happens inside the SE itself and not in the OS where it could be spoofed. It’s the closest thing to a hardware wallet built into your phone.

Supported Cryptographic Algorithm Elliptical Curves

Elliptical Curves

Here’s where EVM wallet development hits its biggest wall. The Secure Enclave only supports ECDSA on the NIST P-256 curve (kSecAttrKeyTypeECSECPrimeRandom). It does not support:

secp256k1 — the elliptic curve used by Ethereum and Bitcoin ❌
ed25519 — used by Solana ❌
Arbitrary data storage — you can’t put a 24-word mnemonic inside the SE ❌

You cannot put an Ethereum private key inside the Secure Enclave and have it sign transactions directly. The SE will simply refuse. This is the single biggest constraint in iOS wallet design, and it forces every major mobile wallet into the same architectural workaround.

Encryption Workaround

Since we can’t store secp256k1 keys in the SE directly, we use the SE for what it does support, which is to use that capability to protect what we actually need to store. This is the pattern used by most wallets.

Encryption Workaround

The SE-wrapped encryption key pattern:

Generate a P-256 keypair inside the Secure Enclave, gated by biometric authentication. The private key never leaves the SE.
Generate an AES-256 symmetric key (the “wrapping key”) and store it in the Keychain.
Encrypt the wrapping key using the SE’s P-256 public key. Store the ciphertext.
Encrypt your mnemonic / secp256k1 private keys with the AES key. Store the ciphertext in Keychain or on disk.

To sign an Ethereum transaction:

Biometric prompt triggers → SE unwraps the AES key → AES key decrypts the mnemonic → derive the secp256k1 private key → sign → immediately zero the memory.

The mnemonic is in plaintext for milliseconds, only after a successful biometric prompt, and the root of trust (the SE keypair) is hardware-bound and non-exportable. No amount of JS compromise can extract the SE key.

iOS Simulator Limitations

iOS Simulator

The iOS Simulator runs on your Mac’s x86/ARM processor, which means it doesn’t have a Secure Enclave. Biometric APIs exist in the Simulator, but Face ID is simulated (you trigger it via the menu: Features → Face ID → Matching Face) and kSecAttrTokenIDSecureEnclave operations simply fail or are silently downgraded.

This means you need two code paths:

Simulator: Fall back to standard Keychain storage without SE-backed keys. You can use expo-secure-store directly, or generate a software P-256 key stored in Keychain as a stand-in.
Physical device: Full SE-backed key generation with real biometric gating. NOTE: Due to the additional native modules needed, an Apple Paid Developer account is needed to build and deploy on your device for testing.

In practice, you’d detect this with a runtime check (expo-device's isDevice flag), or wrapping SE key generation in a try/catch that falls back gracefully. Flag your simulator builds clearly in development so you never accidentally test security-critical paths against the fake implementation.

The only way to properly test the full security model is to use real SE keys, real biometrics, and real attestation and load the app onto a physical iPhone via EAS Build or Xcode.

App Demo

We’ll now walkthrough a demo of the application running on iOS device.

https://medium.com/media/965f05c80ef8f40f4c561bc51622bd63/href

Final Code

If you’d like to try the code out yourself, take a look at https://github.com/berachain/guides/tree/main/apps/evm-wallet:

guides/apps/evm-wallet at main · berachain/guides

Next Steps

A few natural directions from here:

WalletConnect integration — letting the wallet connect to dApps via QR code is the feature that makes it actually useful day-to-day. The @walletconnect/web3wallet SDK handles the session management; the tricky part is routing signing requests back through your SE-wrapped key pipeline.

Transaction history — querying an indexer or a block explorer API gives you a proper activity feed without running your own node.

Push notifications for incoming transactions — requires a backend listener (or a webhook from a web service), but transforms the app from a read/sign tool into something that feels live.

❤️ Don’t forget to show some love for this article 👏🏼.

How 2FA Is Possible Thanks to EIP-7951

Manny — Fri, 29 May 2026 13:03:48 GMT

EIP-7951 Allows For Two-Factor Authentication On EVM Chains Like Berachain

How 2FA Is Possible Thanks to EIP-7951

Whenever a finger touches a MacBook or Face ID recognises a face, your identity is confirmed in milliseconds. This is possible thanks to the Secure Enclave, a dedicated security chip that generates and stores a P-256 private key that never leaves the device. The same cryptographic primitive secures billions of phones, laptops, and hardware tokens worldwide. Until recently, Ethereum & Berachain had no efficient way to verify it on-chain. EIP-7951 changes that.

What Is EIP-7951 and P-256?

EIP-7951 introduces native support for understanding signatures that come from devices like your phone or laptop, in the form of a precompile. A precompile is a special contract built directly into the Ethereum and Berachain protocol rather than deployed in Solidity, which means it runs fast and cheap compared to equivalent on-chain code.

That precompile is called P256VERIFY and lives at address 0x100. It performs ECDSA signature verification over the secp256r1 elliptic curve, also known as P-256 or prime256v1. This differs from secp256k1, the curve native to EMV chains that your EOA already uses for signing transactions. P-256 is a NIST-standardised curve built into nearly every piece of modern secure hardware: Apple Secure Enclave, Android Keystore, YubiKeys, HSMs, and FIDO2/WebAuthn authenticators. Both curves provide approximately 128 bits of security, but only secp256k1 was verifiable on EVM chains efficiently until now.

Comparison of secp256k1 vs secp256r1 (Scaled down)

The precompile takes exactly 160 bytes of input, packed as five 32-byte fields:

input = hash (32 bytes)
      | r    (32 bytes)
      | s    (32 bytes)
      | qx   (32 bytes)
      | qy   (32 bytes)

# Example
# hash = 0x2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
# r    = 0xa9f2f9a9c6b1e2d3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6
# s    = 0x4fe342e2fe1a7f9b8ee7eb4a7c0f9e162bce33576b315ececbb6406837bf51f5
# qx   = 0x6b17d1f2e12c4247f8bce6e563a440f277037d812deb33a0f4a13945d898c296
# qy   = 0x4fe342e2fe1a7f9b8ee7eb4a7c0f9e162bce33576b315ececbb6406837bf51f5

On successful verification it returns a single 32-byte word. On failure or invalid input it returns empty bytes:

// Valid signature
0x0000000000000000000000000000000000000000000000000000000000000001

// Invalid signature or bad input
0x (empty)

The cost is 6900 gas. Before EIP-7951, verifying a P-256 signature required a full Solidity elliptic curve library, which typically consumed 200,000 to 300,000 gas per verification. The precompile reduces that by roughly 97%.

Comparing Ethereum and Berachain P-256 Verification Costs Before & After EIP-7951

The Problem Before EIP-7951

Before this precompile, verifying a P-256 signature on Ethereum required implementing the full elliptic curve arithmetic in Solidity. This was not just expensive in gas terms; it was often prohibitively slow, error-prone, and impractical for production use. Hardware-backed signing through devices like the Secure Enclave or WebAuthn authenticators was theoretically possible but had no viable path to production on L1.

The problems ran deeper than gas costs. Every aspect of the user experience was built around assumptions that excluded mainstream users: you needed a seed phrase, you needed ETH in your wallet before you could do anything, and the only signing key Ethereum understood was one you managed yourself. There was no path from Touch ID to a transaction.

UX Before & After EIP-7951

What EIP-7951 Unlocks

Native P-256 verification on EVM chains opens up a category of use cases that were previously either impossible or impractical.

Passkey-native wallets. Users can sign transactions using device biometrics (Face ID, Touch ID, Windows Hello) without ever managing a seed phrase. The signing key lives in hardware and cannot be exported.

WebAuthn as on-chain authentication. FIDO2/WebAuthn devices generate P-256 signatures by default. These can now be verified directly in smart contracts, enabling hardware security keys as account signers.

Multi-factor authentication on-chain. A contract can require both a standard secp256k1 signature and a P-256 signature before executing sensitive operations. This is the basis for the 2FA pattern described below.

Enterprise and institutional signing. Hardware Security Modules (HSMs) and Trusted Execution Environments (TEEs) commonly use P-256. Organizations can now integrate these into their on-chain key management strategies without custom cryptography libraries.

Example 2FA Solidity Contract

The following contract holds funds and executes calls on behalf of its owner. It acts as the account: ETH/BERA lives in the contract, and all transactions originate from it. The owner never sends transactions directly. Instead, anyone (a relayer, a bundler, or the owner themselves) can submit a call to execute, and the contract verifies two things before proceeding: that the request was authorised by the owner's EOA key, and that the owner's hardware device confirmed it with a P-256 signature.

2FA Solidity Contract Sequence Diagram

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

contract TwoFactorAccount {
    address public constant P256VERIFY = address(0x100);

    // secp256k1 curve order — used for low-s malleability check
    uint256 constant SECP256K1_N = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141;

    address public owner;
    uint256 public p256PublicKeyX;
    uint256 public p256PublicKeyY;
    uint256 public nonce;

    constructor(
        address _owner,
        uint256 _p256x,
        uint256 _p256y
    ) {
        owner = _owner;
        p256PublicKeyX = _p256x;
        p256PublicKeyY = _p256y;
    }

    function execute(
        address target,
        uint256 value,
        bytes calldata data,
        uint8 v,
        bytes32 r,
        bytes32 s,
        bytes32 p256R,
        bytes32 p256S
    ) external {
        // Contract computes the intent hash from calldata it already has.
        // Binds target, value, calldata, nonce and chain to prevent replay.
        bytes32 intentHash = keccak256(
            abi.encodePacked(target, value, data, nonce, block.chainid)
        );

        bytes32 ethHash = keccak256(
            abi.encodePacked("\x19Ethereum Signed Message:\n32", intentHash)
        );

        // Signature malleability: enforce canonical low-s for the EOA sig.
        // For any valid (r, s), (r, n-s) is also valid. Requiring s <= n/2
        // ensures only one form is accepted, preventing replays via the
        // alternate form.
        require(uint256(s) <= SECP256K1_N / 2, "Non-canonical s");

        // Verify owner EOA signature over the intent hash
        address recovered = ecrecover(ethHash, v, r, s);
        require(recovered == owner, "Invalid owner signature");

        // Signature malleability: bind p256Hash to intentHash so the hardware
        // sig is scoped to the same nonce-bound payload as the EOA sig.
        // Prevents a stale P-256 sig from a previous tx being recycled.
        bytes memory p256Input = abi.encodePacked(
            intentHash,
            p256R,
            p256S,
            p256PublicKeyX,
            p256PublicKeyY
        );
        (bool success, bytes memory result) = P256VERIFY.staticcall(p256Input);
        require(
            success && result.length == 32 && uint256(bytes32(result)) == 1,
            "Invalid P-256 signature"
        );

        // Both factors verified — execute from the contract
        nonce++;
        (bool executed,) = target.call{value: value}(data);
        require(executed, "Execution failed");
    }

    receive() external payable {}
}

The contract holds the ETH and initiates every call via target.call. The submitter of the execute transaction pays gas but has no ability to alter what gets called: the target, value, and calldata are all bound into the signed intent hash. The owner signs that intent offline with their EOA key and confirms it on their hardware device, then hands both signatures to whoever is submitting. The nonce prevents the same pair of signatures from being replayed.

Taking It Further with EIP-7702

The contract above works well for newly deployed smart accounts. But what about existing EOAs that already hold assets and have history?

EIP-7702 solves this. It introduces a new transaction type that lets an EOA temporarily delegate its code to a smart contract implementation. In a single transaction, an EOA can point to the TwoFactorAccount implementation above, making it behave like a smart contract while keeping the same address and balance. The delegation is reversible: the EOA can remove it with another EIP-7702 transaction.

This means a user with an existing MetaMask wallet can upgrade it to require 2FA for high-value operations without migrating funds, without changing addresses, and without deploying a new contract. Their wallet address stays the same. Their ETH and tokens stay put. They simply gain additional validation logic.

A practical flow looks like this: the user submits an EIP-7702 authorization that delegates their EOA to the TwoFactorAccount implementation and registers their Secure Enclave public key. From that point on, sensitive transactions require both their existing private key and a Touch ID confirmation. The P-256 signature from the Secure Enclave is verified on-chain by the P256VERIFY precompile.

One important caveat: EIP-7702 does not make transactions gasless. The transaction still needs to be submitted by someone who can pay gas. In practice this means relying on a bundler or relayer service, which introduces a trust dependency that developers and users should account for in their threat model.

Security Caveats

Signature malleability. Unlike secp256k1 on Ethereum, P-256 signatures under NIST FIPS 186–5 are not required to be non-malleable. A valid signature (r, s) has a counterpart (r, n - s) that is also valid. Applications that require non-malleability, for example to prevent transaction replays in edge cases, must implement additional checks at the application layer. The nonce pattern shown in the example contract above handles replay protection, but developers should be explicit about this requirement.

Threats can include Mempool front-running or re-used P-256 signatures.

Signature Malleability Example

Demo & Full Code Repository

Here is a demo of the entire project and the full source code.

Project Demo

See the full interaction of the app here:

https://medium.com/media/2d980290bb542262168ffd9630ec7a35/href

GitHub Full Source Code

Full source code can be found here:
https://github.com/berachain/guides/tree/main/apps/eip7951

guides/apps/eip7951 at main · berachain/guides

Next Steps

EIP-7951 is a small addition to the EVM chains with significant practical implications. A single precompile at 0x100 and 6900 gas bridges the gap between the hardware authentication infrastructure already in billions of devices and the on-chain verification that EVM smart contracts need.

Combined with EIP-7702, it enables existing EOAs to gain smart account capabilities including hardware-backed 2FA without migration, without new addresses, and without abandoning existing tooling.

The 2FA pattern explored in this article is one application. Others worth exploring include:

Passkey-native onboarding where new users never see a seed phrase and authenticate entirely through device biometrics.
WebAuthn session keys for dApps that want hardware-grade authentication without wallet popups on every interaction.
HSM-backed institutional signers for DAOs and protocols that need auditable, hardware-bound signing authority.
Cross-chain identity using P-256 keys that are already recognised by enterprise blockchains and interoperability protocols.
Recovery mechanisms where a Secure Enclave key acts as a guardian for account recovery without a centralised custodian.

The authentication hardware already exists in your users’ pockets. EIP-7951 gives EVM chains the ability to trust it.

If you want to build more on Berachain and see more examples. Take a look at our Berachain GitHub Guides Repo for a wide variety of implementations.

❤️ Don’t forget to show some love for this article 👏🏼.

Building AI Agent Micropayment APIs with x402 on Berachain

Manny — Tue, 12 May 2026 15:53:40 GMT

Understanding x402 & Using $HONEY To Pay For An API Request

Building an x402 API That Accepts Berachain $HONEY Payments

x402 is a payments standard built on HTTP that brings a 402 Payment Required status code back to use. The core idea is straightforward: a user or a client makes a request for some data from a server and instead of returning the result right away it responds with a 402 status code and a set of payment instructions (token address, amount, recipient, etc). The client pays, attaches proof to a follow-up request, and the server verifies and responds with the actual payload. No subscriptions, no API keys, no billing dashboards. Just a token transfer and a retry.

x402 Sequence Diagram

In this tutorial we’re using x402 to build a weather API that accepts Honey ($HONEY), Berachain’s native stablecoin, as the price of admission. Hit the endpoint without paying and you get a 402 with the Honey payment terms. Send the required amount to the server's wallet on Berachain and retry with your transaction hash, and the weather data comes back. The goal is to show how straightforward it is to build a resource that any HTTP client (or AI agent) can discover, pay for, and consume, using a stable on-chain token as the unit of exchange.

weather-x402 app

Prerequisites

Before starting, make sure you have the following:

Bun installed (curl -fsSL https://bun.sh/install | bash)
Basic familiarity with TypeScript
Metamask wallet Chrome extension installed with Smart Accounts enabled and Bepolia network configured
Testnet BERA (for gas) and testnet Honey (https://bepolia.faucet.berachain.com)
Thirdweb account — We will set this up
Cursor, Claude Code, or AI centric IDE

NOTE: Currently Honey and USDC have the functionality required for x402

Setting Up Thirdweb Facilitator

The most involved part of setup is obtaining the right API keys and server wallet needed for the x402 facilitator.

NOTE: We are using Bepolia Testnet (Chain ID 80069) because if you wanted to process transactions on Mainnet, you would need to set up a paid plan with Thirdweb.

Setting Up A Project

The first thing we’ll need to do is sign up to Thirdweb and create a new project.

https://thirdweb.com/login

Once you’ve signed in, you’ll probably need to create a team at https://thirdweb.com/account if you haven’t done so already. I’m going to assume you have gone through the process and you have maybe set up a free account for that team.

After you’ve created a team, go into its projects and create a new one.

Thirdweb Create Project

While configuring the new project, we’re going to ensure that requests can be made from localhost:3000, which will be our backend api.

Configuring New Project

Copy your Client ID and your Secret Key and store them somewhere so that we can reference this later in our code.

Thirdweb Project API Keys

Setup Server Wallet

Now that we have our project and API keys set up, the next thing we’ll need to do is create a server wallet. The server wallet is that will execute the transactions on behalf of the user for x402. We’ll be building this on Bepolia Testnet, but if you were running this on Berachain Mainnet it would likely need to have a balance of the native gas token BERA in order to sponsor those transactions.

When the wallet wanting to pay for a resource is ready, it doesn’t submit an on-chain transaction itself. Instead, it creates an offchain cryptographic signature (a payment authorization) that it attaches to the HTTP request. A facilitator server then verifies that signature and uses its own server wallet to settle the payment on-chain on the client’s behalf. The server wallet is what actually broadcasts the transaction and covers gas, which is why facilitators like Thirdweb’s use managed server wallets to handle this across many chains without manual gas management.

Thirdweb Server Wallets

Now that we have our API Keys and the Server Wallet address, we can start building.

Building Our Backend API With Cursor

Using Cursor, let’s start with a simple prompt using Opus 4.7 in plan mode to create the x402 backend API

I want to build a backend api that let's a user perform an x402 request to get the weather of a city in the US and process a payment on the Berachain EVM network.
It should include the ability to:
- Make a request that doesn't require an x402 payment to ensure that the request for the weather is working correctly
- Ability to make a x402 request for the weather of a city and require a payment
- Process the payment leveraging a facilitator from Thirdweb
- The payment should be made using Berachain's stablecoin called $HONEY

Make sure to look up Thirdweb's docs on x402.

Use the following APIs
- https://nominatim.openstreetmap.org/search?q=${encodeURIComponent(city)}&format=json&limit=1
- https://api.weather.gov/points/${lat.toFixed(4)},${lon.toFixed(4)}

For the tech stack
- Use bun as the package manager
- Use viem for any evm or wallet interactions
- Make sure it's built with TypeScript
- Utilizing Hono instead of Express
- Use Thirdweb as a Facilitator
- It should be built on top Berachain Bepolia Testnet - Chain ID 80069
- It should have have .env and .env.example with presets

Build this in a folder called /api

This is a good starting point and will definitely require a few more prompts to get it to place that we need. This is what was generated for me, but if you’d like to see the working code, see the full github repository link further down.

x402 Backend API

Once the project is setup, we’ll need to make sure our .env file has the right Thirdweb API keys, the receiver of the funds is setup, and we give the server wallet address we generated.

Cursor Backend Configuing Environment Variables

Building Our Frontend With Cursor

For the frontend, let’s work with the following prompt to plan things out:

I want to build a frontend that allows a user to connect their EVM wallet with the Berachain network to the page and perform the following:
1 - Make a request leveraging the non-x402 endpoint to get the weather for a city and show the response
2 - Make a request to the x402 weather api and return the response for the payment details
3 - Make a request to the x402 weather api, prompt the evm wallet to sign the necessary transaction, and pass the signature to process the payment through the x402 endpoint

These should be 3 different card sections for the user to interact with and shouldn't be dependent of each other.

Ensure that the backend has CORS enabled correctly to allow for requests coming from the frontend.

The tech stack should include:
- Use bun as the package manager
- Use viem for any evm or wallet interactions
- Make sure it's built with TypeScript
- Use React with Vite
- Ensure there the right integrations with Thirdweb's x402 facilitator
- It should be built on top Berachain Bepolia Testnet - Chain ID 80069
- It should have have .env and .env.example with presets

This should generate quite a bit, and this may take some additional prompts in terms of getting it to read through Thirdweb’s documentation and x402 to fully understand how to retrieve the signature and pass it to the x402 payment gated API.

x402 Web

The frontend in this case will need the Thirdweb Client ID, in order to make the requests to Thirdweb.

x402 Frontend Configuring Environment Variables

Now we’re ready to run the backend and the frontend in two different terminals and get it working together.

x402 Project In Action

The first request we’re going to make sure that the weather API works as expected.

Successful Free Request

Next, we just want to see what the request for the x402 endpoint returns when it expects a payment and responds with instructions.

x402 API Endpoint Payment Instructions

Lastly, we’ll put that all together by connecting our wallet, getting the instructions for the x402 payment, signing a transaction, and sending that to validate and retrieve data.

NOTE: It’s not uncommon where it comes back with an error that the simulation fails. In those cases just try again and it should go through.

Successful x402 API Transaction Paid with Berachain $HONEY

This demonstrates the full cycle of getting payment instructions and making an x402 payment with Berachain’s native stablecoin $HONEY in order to receive the API response.

Full Code Project

If you’d like to run the code yourself, you can check out the full source code and results from the project here:
https://github.com/berachain/guides/tree/main/apps/x402

guides/apps/x402 at main · berachain/guides

Next Steps

Now that you’ve built a working AI-native micropayment system on Berachain, here are some ideas to take it further:

Dynamic pricing. Return different X-Payment-Amount values per route (historical weather costs more than current), or per caller wallet based on usage history.
MCP configuration. Set up an agent wallet MCP which leverages this x402 API.
Multi-token support . Extend the payment headers to list multiple accepted tokens. The fetch_or_get_payment_terms tool can select whichever token the agent wallet holds a balance of.

❤️ Don’t forget to show some love for this article 👏🏼.

Build A Berachain Mobile dApp With WalletConnect & Expo

Manny — Thu, 29 Feb 2024 21:16:39 GMT

How To Build A Mobile Web3 dApp With WalletConnect & React Native Using Expo

Learn To Build A Berachain Mobile DApp

🛠️ Let’s Build A Mobile dApp On Berachain

Most web3 dApps are typically built for web and don’t have much love for mobile. In this tutorial we’re going to change that by building an iOS app with Expo that works with Berachain.

Our mobile dApp will be able to connect our MetaMask mobile wallet, sign a message, and deploy the bytecode for a HelloWorld contract to Berachain Artio (Berachain Testnet).

Berachain Mobile dApp With WalletConnect Web3Modal & Expo

Why Expo?

Expo has been gaining popularity in the React Native space for mobile development and three main reasons why developers are choosing Expo over Native development or just React Native are:

Support for multiple platforms — iOS and Android
Prebuilt components and functionality
Expo EAS (Expo Application Service) which allows for immediate updates versus going through AppStore approvals for each update

https://expo.dev/

WalletConnect & Mobile

WalletConnect has been a staple for most web3 dApps and making sure projects are setup to support has many wallets, while giving easy tooling for developers to get out-of-the-box wallet connection integration with their SDKs.

WalletConnect also has a mobile specific SDK that allows for wallet connections and interactions to happen directly on your mobile device. This is the SDK that we’ll be using for this tutorial.

WalletConnect Web3Modal For React Native

📋 Requirements

Make sure to have the following installed or setup prior to continuing.

NOTE: For the purposes of this tutorial we’ll be focusing on iOS

NVM or Node v20.11.0
Expo Go
Xcode with iOS Simulator
iOS MetaMask Mobile Wallet
Berachain $BERA tokens — (Need Berachain faucet tokens?)

💻 Pre-Step iOS Simulator On Sonoma

With the latest Mac OS Sonoma and Xcode, Apple has decided to create an extra step that would require developers to download a specific runtime simulator that may not be pre-installed.

To start, run Xcode, and go to Window > Devices & Simulators. This will open up a new window. Select Simulators in the top left, and from the dropdown for Device Type select iPhone 15 Pro Max and for OS Version choose Download more simulator runtimes….

Xcode Simulator Runtimes

This will open another window to then download iOS 17.2.

Xcode Simulator Runtimes Download Platforms

Wait until this download completes and double check that your Simulator.app has successfully downloaded by running:

open /Applications/Xcode.app/Contents/Developer/Applications/Simulator.app;

iOS Simulator Successfully Running

📱Building A Berachain Mobile dApp

Now that we our iOS Simulator setup, we should be good to build out our entire mobile application.

WalletConnect Project ID

Before we start coding, we’ll need to make sure that we setup a WalletConnect Project ID at https://cloud.walletconnect.com/app.

If you already have a project id, you can skip this step.

Go the WalletConnect Cloud Sign-In to create a new account.

https://cloud.walletconnect.com/sign-in

When in the dashboard, create a new project.

WalletConnect — Create Project

Enter the details of your project.

WalletConnect — Project Details

Get your project id, we’ll need this for later.

WalletConnect Project ID

Project Setup

Now that we have our WalletConnect project id, let’s create a base expo project and add our needed dependencies.

 npx create-expo-app berachain-walletconnect-expo -t;

# [Expected Prompt & Output]:
# ? Choose a template: › - Use arrow-keys. Return to submit.
#     Blank
# ❯   Blank (TypeScript) - blank app with TypeScript enabled
#     Navigation (TypeScript)
#     Blank (Bare)
# ...
# ✅ Your project is ready!
#
# To run your project, navigate to the directory and run one of the following npm commands.
#
# - cd berachain-walletconnect-expo
# - npm run android
# - npm run ios
# - npm run web

Install our needed dependencies.

NOTE: We’ll be using pnpm which has been known to have some issues with expo. We also recommend using yarn with expo whenever possible.

cd berachain-walletconnect-expo;

pnpm add @web3modal/wagmi-react-native wagmi@1.4.13 viem@1.21.4 @react-native-async-storage/async-storage react-native-get-random-values react-native-svg react-native-modal @react-native-community/netinfo @walletconnect/react-native-compat expo-application expo-linking;
# If in a monorepo / turbo repo, run the following right after in the dir
# pnpm install --ignore-workspace;

# @web3modal/wagmi-react-native - walletconnect react native web3modal
# wagmi@1.4.13 - web3 react hooks (currently only supports v1)
# viem@1.21.4 # js library for interacting with EVM (currently only support
# @react-native-async-storage/async-storage - for local device storage
# react-native-get-random-values - local random val generator
# react-native-svg - native svg support
# react-native-modal - modals support
# @react-native-community/netinfo - api for network info for device
# @walletconnect/react-native-compat - shims / polyfills for additional support
# expo-application - for native app information
# expo-linking - allows for external links to open the browser

Let’s test that our app is working correctly — hint it won’t 😅.

Note: This is an issue specifically with pnpm. If you did everything with yarn then this won’t happen.

# FROM: ./berachain-walletconnect-expo;

pnpm ios;

# [Expected Output]:
#

Expo Not Working — Expected

⚠️ The PNPM Expo Fix

If you’re using yarn you can still make these modifications and it’ll work for all package managers.

To fix this specific pnpm issue, we’ll need to make 3 modifications to our project.

1 — Install Babel Runtime Dependency

# FROM: ./berachain-walletconnect-expo;

pnpm add -D @babel/runtime;

2 — Modify Package JSON App Entry

File: ./package.json

{
  "name": "berachain-walletconnect-expo",
  "version": "1.0.0",
-  "main": "node_modules/expo/AppEntry.js",
+ "main": "index.ts",
  "scripts": {
    "start": "expo start",
    "android": "expo start --android",
    "ios": "expo start --ios",
    "web": "expo start --web"
  },
  "dependencies": {
    "@react-native-async-storage/async-storage": "^1.22.1",
    "@react-native-community/netinfo": "^11.3.0",
    "@walletconnect/react-native-compat": "^2.11.1",
    "@web3modal/wagmi-react-native": "^1.2.0",
    "expo": "~50.0.7",
    "expo-application": "^5.8.3",
    "expo-status-bar": "~1.11.1",
    "react": "18.2.0",
    "react-native": "0.73.4",
    "react-native-get-random-values": "^1.10.0",
    "react-native-modal": "^13.0.1",
    "react-native-svg": "^14.1.0",
    "viem": "1.21.4",
    "wagmi": "1.4.13"
  },
  "devDependencies": {
    "@babel/core": "^7.20.0",
    "@types/react": "~18.2.45",
    "typescript": "^5.1.3"
  },
  "private": true
}

3 — Add New Entry File & Move Our App.tsx

# FROM: ./berachain-walletconnect-expo;

touch index.ts;
mkdir app;
mv App.tsx app;

File: ./index.ts

// Imports
// ========================================================
import { registerRootComponent } from "expo";

// Main App
// ========================================================
import App from "./app/App";

// registerRootComponent calls AppRegistry.registerComponent('main', () => App);
// It also ensures that whether you load the app in Expo Go or in a native build,
// the environment is set up appropriately
registerRootComponent(App);

Let’s try this again, with pnpm ios and we should get the following working. This should also work with yarn or npm as well.

Expo iOS Simulator Working After PNPM Fix

Styling Our Project

For styling, we’re going to use Tailwind with Nativewind to keep that same consistent styling with all of our app.

These next few steps, are a few but once it’s setup, it’ll make sure that we have Tailwind configured correctly.

# FROM: ./berachain-walletconnect-expo;

pnpm add nativewind@^4.0.1 tailwindcss react-native-css-interop;
npx tailwindcss init;

# Move our main App.tsx to an app directory for better tailwind changes
mkdir app;
mv App.tsx app/;

Make the appropriate modification to our newly generated tailwind.config.js file.

File: ./tailwind.config.js

/** @type {import('tailwindcss').Config} */
module.exports = {
  // NOTE: Update this to include the paths to all of your component files.
  content: [
    "./app/**/*.{js,jsx,ts,tsx}", 
    "./components/**/*.{js,jsx,ts,tsx}"
  ],
  presets: [require("nativewind/preset")],
  theme: {
    extend: {},
  },
  plugins: [],
}

Create a new global.css and add Tailwind styles.

# FROM: ./berachain-walletconnect-expo;

touch global.css;

File: ./global.css

@tailwind base;
@tailwind components;
@tailwind utilities;

@layer base {
  .App {
    @apply bg-[#F47226] text-[#2E1E1A] flex w-full h-full items-center justify-center;
  }

  .H1 {
    @apply text-lg mb-2 block font-semibold text-[#121312] text-center;
  }

  .Text {
    @apply mb-2 text-[#2E1E1A] block;
  }

  .TextInput {
    @apply bg-white text-base h-12 px-2 align-text-top rounded w-full mb-4;
  }

  .TextError {
    @apply text-red-800 bg-red-200 mb-2 text-base p-4;
  }

  .Button {
    @apply bg-[#2E1E1A] h-12 flex items-center justify-center rounded-lg mb-4 w-full;
  }

  .Code {
    @apply block bg-[#ff843d] whitespace-nowrap overflow-scroll mb-4 text-[#874c2a] text-base h-12 leading-[3rem] px-2 rounded w-full;
  }
  
  .Connect {
    @apply my-4 block;
  }

  .Balance {
    @apply block w-full px-8;
  }

  .SignMessage {
    @apply block w-full px-8;
  }

  .Deploy {
    @apply block w-full px-8;
  }
}

Modify our babel.config.js to support nativewind.

File: ./babel.config.js

module.exports = (api) => {
  api.cache(true);
  return {
    presets: [
      ["babel-preset-expo", { jsxImportSource: "nativewind" }],
      "nativewind/babel",
    ],
  };
};

Generate a new metro.config.js file which will help with build.

# FROM: ./berachain-walletconnect-expo;

npx expo customize metro.config.js;

Make some modifications to that config file.

File: ./metro.config.js

// Learn more https://docs.expo.io/guides/customizing-metro
const { getDefaultConfig } = require('expo/metro-config');
+ const { withNativeWind } = require('nativewind/metro');

/** @type {import('expo/metro-config').MetroConfig} */
- const config = getDefaultConfig(__dirname);
+ const config = getDefaultConfig(__dirname, { isCSSEnabled: true })

- module.exports = config;
+ module.exports = withNativeWind(config, { input: './global.css' });

Let’s modify our main App.tsx and replace everything with the following code.

File: ./app/App.tsx

// Imports
// ========================================================
import { StatusBar } from 'expo-status-bar';
import { Text, View } from 'react-native';
import '../global.css';

// Main App Component
// ========================================================
export default function App() {
  return (
    
      
      Berachain WalletConnect Expo Example
      Demonstrating how to build mobile dApps
    
  );
};

Run our app again and we should see the following.

Berachain Mobile iOS dApp Working With Tailwind

Let’s also add an SVG logo to our app as a separate component.

# FROM: ./berachain-walletconnect-expo;

mkdir components;
mkdir components/Icons;
touch components/Icons/index.tsx;

Add the following code to our new icons file.

File: ./components/Icons/index.tsx

// Imports
// ========================================================
import Svg, { Path } from "react-native-svg";

// Icons
// ========================================================
export const Logo = ({ className = '', width = 128, height = 128  }) =>

Next we just need to modify our main App.tsx file to include the logo.

File: ./app/App.tsx

// Imports
// ========================================================
import { StatusBar } from 'expo-status-bar';
import { Text, View } from 'react-native';
import '../global.css';
+ import { Logo } from '../components/Icons';

// Main App Component
// ========================================================
export default function App() {
  return (
    
      
+       
      Berachain WalletConnect Expo Example
      Demonstrating how to build mobile dApps
    
  );
};

Berachain Mobile Web3 Expo App With Berachain Logo

WalletConnect Web3Modal

The next step we’re going to do is add WalletConnect’s Web3Modal support into our Expo app.

The first step will be to configure our environment variables.

Note: Make sure not to commit this to our git repository

# FROM: ./berachain-walletconnect-expo;

touch .env;

Add the following contents and remember to replace the WALLET_CONNECT_PROJECT_ID with the newly created project from WalletConnect Cloud directly.

File: ./.env

# Expo Metadata
EXPO_PUBLIC_METADATA_NAME="Berachain WalletConnect Expo"
EXPO_PUBLIC_METADATA_DESCRIPTION="Berachain WalletConnect Expo Example"
EXPO_PUBLIC_METADATA_URL="https://berachain.com"
EXPO_PUBLIC_METADATA_ICONS="https://avatars.githubusercontent.com/u/96059542"
EXPO_PUBLIC_METADATA_REDIRECT_NAME="YOUR_APP_SCHEME://"
EXPO_PUBLIC_METADATA_REDIRECT_UNIVERSAL="YOUR_APP_UNIVERSAL_LINK.com"

# WalletConnect - See https://cloud.walletconnect.com
EXPO_PUBLIC_WALLET_CONNECT_PROJECT_ID="YOUR_PROJECT_ID"

# Chain
EXPO_PUBLIC_CHAIN_ID=80085
EXPO_PUBLIC_CHAIN_NAME="berachainTestnet"
EXPO_PUBLIC_CHAIN_NETWORK="Berachain"
EXPO_PUBLIC_CHAIN_NATIVECURRENCY_DECIMALS=18
EXPO_PUBLIC_CHAIN_NATIVECURRENCY_NAME="Bera Token"
EXPO_PUBLIC_CHAIN_NATIVECURRENCY_SYMBOL="BERA"
EXPO_PUBLIC_CHAIN_RPC_URL="https://rpc.ankr.com/berachain_testnet"
EXPO_PUBLIC_CHAIN_BLOCKEXPLORER_NAME="Beratrail"
EXPO_PUBLIC_CHAIN_BLOCKEXPLORER_URL="https://artio.beratrail.io"

Now that we have this setup, we’re going wrap our main App.tsx with some of the configured providers from WalletConnect that adds its own configuration to the wagmi library.

# FROM: ./berachain-walletconnect-expo;

mkdir providers;
touch providers/index.tsx;
touch providers/wagmi.tsx;

First up is configuring our wagmi provider. This will ensure that we can take advantage of all of wagmi’s hooks but also some default functionality built into WalletConnet Web3Modal.

File: ./providers/wagmi.tsx

// Imports
// ========================================================
import "@walletconnect/react-native-compat";
import {
  createWeb3Modal,
  defaultWagmiConfig,
} from "@web3modal/wagmi-react-native";
import { defineChain } from "viem";
import { WagmiConfig } from "wagmi";

// Config
// ========================================================
// 1. Get projectId at https://cloud.walletconnect.com
const projectId = `${process.env.EXPO_PUBLIC_WALLET_CONNECT_PROJECT_ID}`;

if (!projectId) throw Error('Error: Missing `EXPO_PUBLIC_WALLET_CONNECT_PROJECT_ID`.');

// 2. Create config for our app - defined by our env vars
const metadata = {
  name: `${process.env.EXPO_PUBLIC_METADATA_NAME}`,
  description: `${process.env.EXPO_PUBLIC_METADATA_DESCRIPTION}`,
  url: `${process.env.EXPO_PUBLIC_METADATA_URL}`,
  icons: [`${process.env.EXPO_PUBLIC_METADATA_ICONS}`],
  redirect: {
    native: `${process.env.EXPO_PUBLIC_METADATA_REDIRECT_NATIVE}`,
    universal: `${process.env.EXPO_PUBLIC_METADATA_REDIRECT_UNIVERSAL}`,
  },
};

// 3. Configure our custom chain - Note this is needed for wagmi and viem v1
/**
 * @dev Custom chain configuration
 */
const chainConfiguration = defineChain({
 id: parseInt(`${process.env.EXPO_PUBLIC_CHAIN_ID}`),
 name:`${process.env.EXPO_PUBLIC_CHAIN_NAME}`,
 network: `${process.env.EXPO_PUBLIC_CHAIN_NETWORK}`,
 nativeCurrency: {
  decimals: parseInt(`${process.env.EXPO_PUBLIC_CHAIN_NATIVECURRENCY_DECIMALS}`),
  name: `${process.env.EXPO_PUBLIC_CHAIN_NATIVECURRENCY_NAME}`,
  symbol:`${process.env.EXPO_PUBLIC_CHAIN_NATIVECURRENCY_SYMBOL}`,
 },
 rpcUrls: {
  default: {
   http: [`${process.env.EXPO_PUBLIC_CHAIN_RPC_URL}`],
  },
  public: {
   http: [`${process.env.EXPO_PUBLIC_CHAIN_RPC_URL}`],
  },
 },
 blockExplorers: {
  default: { 
      name: `${process.env.EXPO_PUBLIC_CHAIN_BLOCKEXPLORER_NAME}`,
      url: `${process.env.EXPO_PUBLIC_CHAIN_BLOCKEXPLORER_URL}` 
    },
 },
});

/**
 * @dev supported chains
 */
const chains = [chainConfiguration];

/**
 * 
 */
const wagmiConfig = defaultWagmiConfig({ chains, projectId, metadata });

// 4. Create modal configuration
createWeb3Modal({
  projectId,
  chains,
  wagmiConfig,
});

// Provider
// ========================================================
export default function Wagmi({ children }: { children: React.ReactNode }) {
  return {children}
};

Next, to keep things clean, we’ll modify our main provider file that will wrap our entire application. This helps to keep our App.tsx file clean, and allows us to add more providers easily with our main provider wrapper.

File: ./providers/index.tsx

// Imports
// ========================================================
import WagmiProvider from "./wagmi";

// Root Provider
// ========================================================
export default function RootProvider({ children }: { children: React.ReactNode }) {
  return {children}
};

Then we’ll want this root provider to wrap our App.tsx and we’ll also add our web3modal button.

File: ./app/App.tsx

// Imports
// ========================================================
import { StatusBar } from "expo-status-bar";
import { Text, View } from "react-native";
import "../global.css";
import { Logo } from "../components/Icons";
+ import RootProvider from "../providers";
+ import { Web3Modal } from "@web3modal/wagmi-react-native";

// Main App Component
// ========================================================
export default function App() {
 return (
+   
   
    
+     
    
    Berachain WalletConnect Expo Example
    Demonstrating how to build mobile dApps
   
+   
 );
}

Connect Button

Now that the app fully supports WalletConnect, we can now add support for a connect button. We’re going to put this in a separate file to make it easier for us to modify by itself.

# FROM: ./berachain-walletconnect-expo;

mkdir components/Connect;
touch components/Connect/index.tsx;

File: ./components/Connect/index.tsx

// Imports
// ========================================================
import { W3mButton } from "@web3modal/wagmi-react-native";
import { View } from "react-native";

// Component
// ========================================================
export default function Connect() {
 return (
  
   {/* Customizing the web3modal button requires passing it certain props */}
       connectStyle={{
     backgroundColor: "#2E1E1A",
    }}
    accountStyle={{
     backgroundColor: "#2E1E1A",
    }}
   />
  
 );
}

Let’s add this button to our App.tsx file.

// Imports
// ========================================================
import { StatusBar } from "expo-status-bar";
import { Text, View } from "react-native";
import "../global.css";
import { Logo } from "../components/Icons";
+ import Connect from "../components/Connect";
import RootProvider from "../providers";
import { Web3Modal } from "@web3modal/wagmi-react-native";


// Main App Component
// ========================================================
export default function App() {
 return (
  
   
    
        
    
    Berachain WalletConnect Expo Example
    Demonstrating how to build mobile dApps
+     
   
  
 );
}

We should now have a our connect button supported, but you’ll quickly notice there isn’t a way to connect with our wallet on our mobile because MetaMask isn’t installed on Simulator.

Berachain WalletConnect Web3Modal Working

When you click the Connect button, we’ll see that there are zero wallets available.

Berachain WalletConnect Web3Modal Cannot Connect To Wallet On Simulator

This is the part where we can take advantage of Expo Go on our phone to connect with our existing wallets.

Note: Make sure that you have MetaMask Mobile installed on your phone and configure your MetaMask mobile to have a new network with Berachain.

If you notice when we run pnpm ios a QR code shows up. We should be able to use that with the Expo Go app to load the app directly into our phone.

Warp Terminal Running Expo With QR Code

Now when we use our iPhone’s camera, we can connect and open up our app in Expo Go.

Connecting To Expo Go On With Your iPhone

When the app loads on our phone, we should be able to tap Connect, be presented with MetaMask as an option, select MetaMask, confirm our connection via the MetaMask app, and then be pushed back to the app to confirm that we’re connected.

Berachain Expo WalletConnect Successfully Connecting To MetaMask

Display $BERA Balance

Now that we have successfully connected our account with MetaMask, let’s add a basic component that displays our current balance on Berachain.

Note: Make sure to switch your MetaMask wallet to the Berachain Artio Testnet Network before hand.

Our component will check if the account is already connected and the make a request to show the current balance.

# FROM: ./berachain-walletconnect-expo;

mkdir components/Balance;
touch components/Balance/index.tsx;

Let’s add the following code for our new Balance component.

File: ./components/Balance/index.tsx

// Imports
// ========================================================
import { View, Text } from "react-native";
import { useAccount, useBalance } from "wagmi";

// Component
// ========================================================
export default function Balance() {
  // Hooks
  const { isConnected, address } = useAccount();
  const { data, isError, isLoading } = useBalance({
    address
  });

  // Return
  /**
   * If still loading, show a loading state
   */
  if (isLoading)
    return Fetching balance...;


  /**
   * Show error if having a problem fetching the balance
   */
  if (isError)
    return (
      Error fetching balance
    );

  /**
   * If not connected don't show anything
   */
  if (!isConnected) return null;


  /**
   * Successfully connected
   */
  return (
    
      Balance
      {(parseInt((data?.value ?? '').toString()) / 1000000000000000000).toFixed(2)} $BERA
    
  );
}

Then we’ll add the Balance component to our App.tsx.

File: ./app/App.tsx

// Imports
// ========================================================
import { StatusBar } from "expo-status-bar";
import { Text, View } from "react-native";
import "../global.css";
import { Logo } from "../components/Icons";
import Connect from "../components/Connect";
+ import Balance from "../components/Balance";
import RootProvider from "../providers";
import { Web3Modal } from "@web3modal/wagmi-react-native";

// Main App Component
// ========================================================
export default function App() {
 return (
  
   
    
        
    
    Berachain WalletConnect Expo Example
    Demonstrating how to build mobile dApps
    
+     
   
  
 );
}

Now when we connect with MetaMask, we should see our $BERA balance.

Berachain WalletConnect Expo Showing $BERA Balance Functionality

Wallet Sign Message

On top of every basic RPC request, we also want to get some basic wallet interactions going. The simplest version would be signing a message with your MetaMask wallet and getting a signature.

We’re going to build an input that accepts a message, prompts the user’s MetaMask wallet to sign the message, and output the signature.

We’ll first create the file.

# FROM: ./berachain-walletconnect-expo;

mkdir components/SignMessage;
touch components/SignMessage/index.tsx;

Add the functionality to it.

File: ./components/SignMessage/index.tsx

// Imports
// ========================================================
import { useState } from "react";
import { View, Pressable, Text, TextInput } from "react-native";
import { useAccount, useSignMessage } from "wagmi";

// Component
// ========================================================
export default function SignMessage() {
 // Hooks
 const [message, setMessage] = useState("");
 const [signature, setSignature] = useState("(Signature will show up here)");
 const [error, setError] = useState("");
 const { isConnected, address } = useAccount();
 const { signMessageAsync } = useSignMessage();

 // Functions
  /**
   * @dev Handles signing message
   */
 const onPressSignMessage = async () => {
  console.group("onPressSignMessage");
  setError("");

  try {
   const signature = await signMessageAsync({
    message,
   });
   setSignature(signature);
  } catch (error: unknown) {
   console.error({ error });
   setError("Error signing message.");
  }
  console.groupEnd();
 };

 // Return
  /**
   * If not connected and no address, then don't show anything
   */
 if (!isConnected || !address) return null;

 return (
  
   Sign Message
       className="TextInput"
    placeholder="Message to sign"
    onChangeText={setMessage}
    value={message}
   />
   Signature Generated
       className="Code"
   >{signature}
       className="Button"
    onPress={onPressSignMessage}
   >
    Sign Message
   

   {error ? (
    
     {error}
    
   ) : null}
  
 );
}

We’ll add the Sign Message functionality to our App.tsx.

File: ./app/App.tsx

// Imports
// ========================================================
import { StatusBar } from "expo-status-bar";
import { Text, View } from "react-native";
import "../global.css";
import { Logo } from "../components/Icons";
import Connect from "../components/Connect";
import Balance from "../components/Balance";
+ import SignMessage from "../components/SignMessage";
import RootProvider from "../providers";
import { Web3Modal } from "@web3modal/wagmi-react-native";

// Main App Component
// ========================================================
export default function App() {
 return (
  
   
    
        
    
    Berachain WalletConnect Expo Example
    Demonstrating how to build mobile dApps
    
    
+     
   
  
 );
}

We should now see the functionality of inputting a message, prompting our wallet to sign the message, and seeing the generated signature.

Berachain WalletConnect Wallet Signature Working With Ooga Booga

Deploy Contract

The last piece of functionality I want to add to this app is the ability to deploy a contract’s bytecode directly from the mobile app itself. This would essentially prompt our wallet to initiate a transaction that would deploy a contract to Berachain.

To start, let’s create a new Deploy component.

# FROM: ./berachain-walletconnect-expo;

mkdir components/Deploy;
touch components/Deploy/index.tsx;

We’ll add the following functionality to our Deploy component.

File: ./components/Deploy/index.tsx

// Imports
// ========================================================
import { useState } from "react";
import { Pressable, Text } from "react-native";
import { useAccount, useWaitForTransaction } from "wagmi";
import { encodeAbiParameters } from "viem";
import { openURL } from "expo-linking";

// Constants
// ========================================================
/**
 * @dev ByteCode for HelloWorld Contract see https://github.com/berachain/guides/blob/main/apps/hardhat-viem-helloworld/contracts/HelloWorld.sol
 */
const CONTRACT_BYTECODE =
  "0x60806040523480156200001157600080fd5b5060405162000da238038062000da283398181016040528101906200003791906200021e565b8060009081620000489190620004ba565b507fcbc299eeb7a1a982d3674880645107c4fe48c3227163794e48540a752272235433826040516200007c92919062000638565b60405180910390a1506200066c565b6000604051905090565b600080fd5b600080fd5b600080fd5b600080fd5b6000601f19601f8301169050919050565b7f4e487b7100000000000000000000000000000000000000000000000000000000600052604160045260246000fd5b620000f482620000a9565b810181811067ffffffffffffffff82111715620001165762000115620000ba565b5b80604052505050565b60006200012b6200008b565b9050620001398282620000e9565b919050565b600067ffffffffffffffff8211156200015c576200015b620000ba565b5b6200016782620000a9565b9050602081019050919050565b60005b838110156200019457808201518184015260208101905062000177565b60008484015250505050565b6000620001b7620001b1846200013e565b6200011f565b905082815260208101848484011115620001d657620001d5620000a4565b5b620001e384828562000174565b509392505050565b600082601f8301126200020357620002026200009f565b5b815162000215848260208601620001a0565b91505092915050565b60006020828403121562000237576200023662000095565b5b600082015167ffffffffffffffff8111156200025857620002576200009a565b5b6200026684828501620001eb565b91505092915050565b600081519050919050565b7f4e487b7100000000000000000000000000000000000000000000000000000000600052602260045260246000fd5b60006002820490506001821680620002c257607f821691505b602082108103620002d857620002d76200027a565b5b50919050565b60008190508160005260206000209050919050565b60006020601f8301049050919050565b600082821b905092915050565b600060088302620003427fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff8262000303565b6200034e868362000303565b95508019841693508086168417925050509392505050565b6000819050919050565b6000819050919050565b60006200039b620003956200038f8462000366565b62000370565b62000366565b9050919050565b6000819050919050565b620003b7836200037a565b620003cf620003c682620003a2565b84845462000310565b825550505050565b600090565b620003e6620003d7565b620003f3818484620003ac565b505050565b5b818110156200041b576200040f600082620003dc565b600181019050620003f9565b5050565b601f8211156200046a576200043481620002de565b6200043f84620002f3565b810160208510156200044f578190505b620004676200045e85620002f3565b830182620003f8565b50505b505050565b600082821c905092915050565b60006200048f600019846008026200046f565b1980831691505092915050565b6000620004aa83836200047c565b9150826002028217905092915050565b620004c5826200026f565b67ffffffffffffffff811115620004e157620004e0620000ba565b5b620004ed8254620002a9565b620004fa8282856200041f565b600060209050601f8311600181146200053257600084156200051d578287015190505b6200052985826200049c565b86555062000599565b601f1984166200054286620002de565b60005b828110156200056c5784890151825560018201915060208501945060208101905062000545565b868310156200058c578489015162000588601f8916826200047c565b8355505b6001600288020188555050505b505050505050565b600073ffffffffffffffffffffffffffffffffffffffff82169050919050565b6000620005ce82620005a1565b9050919050565b620005e081620005c1565b82525050565b600082825260208201905092915050565b600062000604826200026f565b620006108185620005e6565b93506200062281856020860162000174565b6200062d81620000a9565b840191505092915050565b60006040820190506200064f6000830185620005d5565b8181036020830152620006638184620005f7565b90509392505050565b610726806200067c6000396000f3fe608060405234801561001057600080fd5b50600436106100365760003560e01c8063a41368621461003b578063fe50cc7214610057575b600080fd5b610055600480360381019061005091906102ad565b610075565b005b61005f6100c1565b60405161006c9190610375565b60405180910390f35b806000908161008491906105ad565b507fcbc299eeb7a1a982d3674880645107c4fe48c3227163794e48540a752272235433826040516100b69291906106c0565b60405180910390a150565b6060600080546100d0906103c6565b80601f01602080910402602001604051908101604052809291908181526020018280546100fc906103c6565b80156101495780601f1061011e57610100808354040283529160200191610149565b820191906000526020600020905b81548152906001019060200180831161012c57829003601f168201915b5050505050905090565b6000604051905090565b600080fd5b600080fd5b600080fd5b600080fd5b6000601f19601f8301169050919050565b7f4e487b7100000000000000000000000000000000000000000000000000000000600052604160045260246000fd5b6101ba82610171565b810181811067ffffffffffffffff821117156101d9576101d8610182565b5b80604052505050565b60006101ec610153565b90506101f882826101b1565b919050565b600067ffffffffffffffff82111561021857610217610182565b5b61022182610171565b9050602081019050919050565b82818337600083830152505050565b600061025061024b846101fd565b6101e2565b90508281526020810184848401111561026c5761026b61016c565b5b61027784828561022e565b509392505050565b600082601f83011261029457610293610167565b5b81356102a484826020860161023d565b91505092915050565b6000602082840312156102c3576102c261015d565b5b600082013567ffffffffffffffff8111156102e1576102e0610162565b5b6102ed8482850161027f565b91505092915050565b600081519050919050565b600082825260208201905092915050565b60005b83811015610330578082015181840152602081019050610315565b60008484015250505050565b6000610347826102f6565b6103518185610301565b9350610361818560208601610312565b61036a81610171565b840191505092915050565b6000602082019050818103600083015261038f818461033c565b905092915050565b7f4e487b7100000000000000000000000000000000000000000000000000000000600052602260045260246000fd5b600060028204905060018216806103de57607f821691505b6020821081036103f1576103f0610397565b5b50919050565b60008190508160005260206000209050919050565b60006020601f8301049050919050565b600082821b905092915050565b6000600883026104597fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff8261041c565b610463868361041c565b95508019841693508086168417925050509392505050565b6000819050919050565b6000819050919050565b60006104aa6104a56104a08461047b565b610485565b61047b565b9050919050565b6000819050919050565b6104c48361048f565b6104d86104d0826104b1565b848454610429565b825550505050565b600090565b6104ed6104e0565b6104f88184846104bb565b505050565b5b8181101561051c576105116000826104e5565b6001810190506104fe565b5050565b601f82111561056157610532816103f7565b61053b8461040c565b8101602085101561054a578190505b61055e6105568561040c565b8301826104fd565b50505b505050565b600082821c905092915050565b600061058460001984600802610566565b1980831691505092915050565b600061059d8383610573565b9150826002028217905092915050565b6105b6826102f6565b67ffffffffffffffff8111156105cf576105ce610182565b5b6105d982546103c6565b6105e4828285610520565b600060209050601f8311600181146106175760008415610605578287015190505b61060f8582610591565b865550610677565b601f198416610625866103f7565b60005b8281101561064d57848901518255600182019150602085019450602081019050610628565b8683101561066a5784890151610666601f891682610573565b8355505b6001600288020188555050505b505050505050565b600073ffffffffffffffffffffffffffffffffffffffff82169050919050565b60006106aa8261067f565b9050919050565b6106ba8161069f565b82525050565b60006040820190506106d560008301856106b1565b81810360208301526106e7818461033c565b9050939250505056fea264697066735822122051a137f3f2f370792efdafdfd52aa1721451dfaa2e804a5236730d97a26f237664736f6c63430008110033";


// Component
// ========================================================
export default function Deploy() {
  // Hooks
  const [isLoading, setIsLoading] = useState(false);
  const [error, setError] = useState('');
  const [transactionHash, setTransactionHash] = useState<`0x${string}` | undefined>();
  const { isConnected, address, connector } = useAccount();

  // Functions
  /**
   * @dev hook that waits for a transaction hash
   */
  const txResult = useWaitForTransaction({
    hash: transactionHash
  });

  /**
   * @dev handles deploying the contract
   */
  const onPressDeployContract = async () => {
    console.group('onPressDeployContract');
    setError('');
    setIsLoading(true);
    try {
      const provider = await connector?.getProvider(); // get's the provider from wagmi directly - needed for the walletconnection
      console.log({ provider });
      console.log({ request: provider?.request });

      // Based on constructor - constructor(string memory _greeting) {
      // encodes the function name and the input of `Hello World!`
      const encodedData = encodeAbiParameters(
        [{ name: "_greeting", type: "string" }],
        ["Hello World!"]
      );

      // Need slide(2) to remove 0x from encodedData at the beginning
      const fullByteCode = `${CONTRACT_BYTECODE}${encodedData.slice(2)}`;

      // Send eth transsaction
      const tx = await provider.request({
        method: "eth_sendTransaction",
        params: [
          {
            from: address,
            data: fullByteCode,
          },
        ],
      });
      console.log({ tx });

      // Set the state transaction hash for `useWaitForTransaction` to wait for it
      setTransactionHash(tx);
    } catch (error: unknown) {
      console.error(error);
      setError('Error could not deploy contract.')
    }
    setIsLoading(false);

    console.groupEnd();
  };

  /**
   * @dev function that handles opening url to the final transaction hash in a block explorer
   */
  const onPressSeeTransaction = () => {
    openURL(`${process.env.EXPO_PUBLIC_CHAIN_BLOCKEXPLORER_URL}/tx/${txResult?.data?.transactionHash}`);
  };

  /**
   * If not connected and no address, then don't show anything
   */
  if (!isConnected || !address) return null;

  return (
    <>
      Deploy Contract
              disabled={isLoading}
        className={"Button"}
        onPress={onPressDeployContract}>
        
          Deploy
        
      

      {isLoading && Loading...}

      {!isLoading && txResult?.data?.transactionHash
        ?           className="Button"
          onPress={onPressSeeTransaction}>
          
            See Successful Transaction
          
        
        : null}
      {error ? {error} : null}
    
  );
}

Now if we go through the process, we should be able to tap Deploy, be prompted by our wallet to confirm the transaction, wait for the transaction to complete and see the transaction on the block explorer.

Berachain WalletConnect Successfully Deployed Contract

🐻 Full Code Repository

If you want to see the final code and see other guides, check out Berachain WalletConnect Expo Guide Code.

guides/apps/walletconnect-expo at main · berachain/guides

🛠️ Want To Build More?

Want to build more on Berachain and see more examples. Take a look at our Berachain GitHub Guides Repo for a wide variety of implementations that include NextJS, Hardhat, Viem, Foundry, and more.

GitHub - berachain/guides: A demonstration of different contracts, languages, and libraries that work with Berachain EVM.

If you’re looking to dive deeper into the details, take a look at our Berachain Docs.

Berachain Docs

Looking For Dev Support?

Make sure to join our Berachain Discord server and check out our developer channels to ask questions.

https://discord.com/invite/berachain

Join the Berachain Discord Server!

❤️ Don’t forget to show some love for this article 👏🏼.

Build A Berachain Mobile dApp With WalletConnect & Expo was originally published in berachain-devs on Medium, where people are continuing the conversation by highlighting and responding to this story.

3 Ways To Configure CORS for NextJS 13 App Router API Route Handlers

Manny — Wed, 30 Aug 2023 21:51:22 GMT

Configure Cross-Origin Resource Sharing For NextJS 13 App Router

How To Configuring CORS For NextJS 13 App Router

If you have ever created a backend and a frontend that both live on different servers trying to communicate with each other, then you will know of CORS issues.

Cross-Origin Resource Sharing (CORS) is an HTTP-header based mechanism that allows a server to indicate any origins (domain, scheme, or port) other than its own from which a browser should permit loading resources.

— https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

Typical CORS Error With NextJS 13

If you have started working with NextJS 13, you’ll also notice that there are a bunch of changes which makes it a bit harder to get up and running with existing libraries, such as nextjs-cors.

I’m going to cover 3 ways that you can configure CORS to allow for resource sharing between a backend API from NextJS and a frontend.

NextJS CORS Environment Setup

In order to get things up running, we’ll be running two services, NextJS as an API, and a simple Client-Side application that makes HTTP requests to the API.

Initial NextJS Project

We’ll be using the default scaffolded NextJS 13 template.


npx create-next-app@latest nextjs13-cors;

# [Expected Prompts]:
# ✔ Would you like to use TypeScript? … No / Yes
# ✔ Would you like to use ESLint? … No / Yes
# ✔ Would you like to use Tailwind CSS? … No / Yes
# ✔ Would you like to use `src/` directory? … No / Yes
# ✔ Would you like to use App Router? (recommended) … No / Yes
# ✔ Would you like to customize the default import alias? … No / Yes
# Creating a new Next.js app in /path/to/nextjs13-cors.

Creating First NextJS AppRouter Endpoint

We won’t bother with creating a fully functional endpoint, but we’ll create both a GET and POST request.

# FROM: ./

mkdir app/api;
mkdir app/api/users;
touch app/api/users/route.ts;

File: app/api/users/route.ts

// Imports
// ========================================================
import { NextResponse, type NextRequest } from "next/server";

// Endpoints
// ========================================================
/**
 * Basic GET Request to simuluate LIST in LCRUD
 * @param request
 * @returns
 */
export const GET = async (request: NextRequest) => {
  // Return Response
  return NextResponse.json(
    {
      data: [
        {
          id: "45eb616b-7283-4a16-a4e7-2a25acbfdf02",
          name: "John Doe",
          email: "john.doe@email.com",
          createdAt: new Date().toISOString(),
        },
      ],
    },
    {
      status: 200,
    }
  );
};

/**
 * Basic POST Request to simuluate CREATE in LCRUD
 * @param request
 */
export const POST = async (request: NextRequest) => {
  // Get JSON payload
  const data = await request.json();

  // Return Response
  return NextResponse.json(
    {
      data,
    },
    {
      status: 200,
    }
  );
};

Testing NextJS GET & POST Requests

You can use an API Client for this, like Postman, or you can use curl in your terminal.

Let’s run our app.

# FROM: /
pnpm dev;

# [Expected Output]:
# > nextjs13-cors@0.1.0 dev /path/to/nextjs13-cors
# > next dev
# 
# - ready started server on [::]:3000, url: http://localhost:3000

Let’s verify that the endpoints work as expected in another Terminal window.

# FROM: /

# TEST 1 - GET Method for NextJS Endpoint
curl --location 'http://localhost:3000/api/users';

# [Expected Output]:
# {"data":[{"id":"45eb616b-7283-4a16-a4e7-2a25acbfdf02","name":"John Doe","email":"john.doe@email.com","createdAt":"2023-08-30T18:17:39.277Z"}]}

# TEST 2- POST Method for NextJS Endpoint
curl --location 'http://localhost:3000/api/users' \
--header 'Content-Type: application/json' \
--data '{
    "hello": "there"
}';
# [Expected Output]:
# {"data":{"hello":"there"}}

Creating Client-Side App

Next we want to use another frontend application to make request to our backend API. To get things working quickly without having to configure React or a server, we’re going to use VanillaJS and a package called http-server.

# FROM: ./

pnpm add -D http-server;

We’ll then create a folder called client with an HTML and JavaScript file that makes HTTP requests to our endpoints.

# FROM: /

mkdir client;
touch client/index.html;
touch client/script.js;

In our HTML file, we’ll put the following:

File: client/index.html



  
    
    
    Client-Side Tests For NextJS Cors
    
  
  
    
      Client-Side Application Testing Cors


      GET


      
        
      


              style="
          width: 500px;
          height: 400px;
          background: #efefef;
          overflow: scroll;
        "
      >

POST

style="
width: 500px;
height: 400px;
background: #efefef;
overflow: scroll;
"
>

Now we can run our client by modifying our package.json file with a new run command called “client”.

If our NextJS server is still running on port 3000 and then try with our client-side application, we should see that we encounter CORS issues.

Now that we have identified the issue, I’ll walk you through 3 ways to fix CORS issues with NextJS 13 AppRouter.

CORS Fix Option 1 — Next Config

One of the quickest ways to get things fixed is to apply a blanket statement over all endpoints, and this can be achieved through NextJS config file, by setting the right headers.

Our NextJS Server will prompt us to restart, and if do and go back to our client-side app, we can see that the request is successful.

One of the downfalls for this option is that you can’t dynamically changes values if you want to allow more than one allowed origin. You would basically have to hard code it, as ENV variables are not read.

This means, if you want to update an allowed origin, update to accept a custom header, and/or configure max age or more, you would need to submit a new PR to have your code redeployed.

CORS Fix Option 2— Route Handler

Option 2 involves creating CORS configurations directly in the route itself. Let’s make sure to comment out our next.config.js headers and start working with the users route directly.

Next we can now modify our route to validate an origin and take those values from our environment variable file. You’ll also notice that in the file, we had to create an explicit OPTIONS request to handle preflight requests.

We should see the same result, where requests are working as expected with no CORS issues.

The main benefit of this method is that we can be very specific as to which endpoint would get specific CORS configurations, and we can leverage environment variables to switch out the values without deploying hard-coded values.

The main downfall of this option is that it’s siloed and doesn’t provide a wider configuration to apply to many endpoints.

CORS Fix Option 3— Middleware (Recommended)

This method I recommend because it’s the best of Option 1, where it applies to multiple endpoints, and Option 2, where you can configure things further through the use of environment variables.

To start, I’m going to comment out what we did in Option 2, so that we can leverage the middleware.

I’m also going to add some additional CORS configurations to our .env file that would be good to have for further customization later.

Next I’m going to create a new file in the root of the project called middleware.ts.

Now if we try our client-side application again with the updated environment variables, we can see that things work as expected for GET and POST HTTP requests.

Full Code Repository

If you want to see all these implementations within a single repository, here is the full repository link to NextJS13 CORS.

What’s Next?

The next step would be to get off localhost and get this code deployed through Vercel to see it working and understand how to create APIs that allow Client-Side Applications to interact with it.

If you got value from this, please give it some love, and please also follow me on X / Twitter (where I’m quite active) @codingwithmanny and Youtube at @codingwithmanny.

Combine Sign-In With Ethereum With Create-T3-App

Manny — Mon, 10 Apr 2023 00:42:37 GMT

Configure SIWE wallet authentication with popular t3 stack which includes NextJS, TypeScript, Tailwind, tRPC, Prisma, and AuthJS (previously NextAuthJS)

Combining Sign-In With Ethereum & Create T3 Stack To Build A Session Authentication App

https://medium.com/media/9f4a5542d98599833465f5e90194fae5/href

What Is The t3 Stack?

Create T3 Stack is definitely one of the fastest ways to get up and running to build an application today. It’s a stack, similar to MEAN, MERN, MAMP, etc. The main benefit is that it comes with is the best tools in the industry to get started building for developers.

The T3 stack comes with NextJS, NextAuth, Prisma, tRPC, Tailwind, and all with TypeScript support. This is everything you need to get started in building an app from scratch and even gives you options to pick and choose which you’d like to include/exclude in your stack to optimize even further.

Give this tutorial a try and you should be able to see how easy it is to build a frontend, backend, session management, and database queries.

https://create.t3.gg

What Is Sign-In With Ethereum (SIWE)?

For developers in web3, Sign-In With Ethereum is a standard that let’s you verify a message by signing it with a crypto wallet, more specifically a Ethereum crypto wallet.

The benefits of this unlock how we could do native verification of messages, and essentially get at authentication. In this tutorial, I’ll be showing you how we can merge SIWE with a full application built with the t3 stack.

https://login.xyz

Requirements

Before we begin, make sure you have the latest version of these requirements installed on your computer.

NVM or Node v18.5.0
npm

Integrating SIWE With T3 Stack

What we’ll be aiming for is getting the create-t3-stack working locally with the Sign-In With Ethereum functionality.

Create New create-t3-app

The first thing we’ll do is scaffold out the stack as a new project.

pnpm create t3-app@latest; # npm create t3-app@latest;

# Expected Output:
#    ___ ___ ___   __ _____ ___   _____ ____    __   ___ ___
#   / __| _ \ __| /  \_   _| __| |_   _|__ /   /  \ | _ \ _ \
#  | (__|   / _| / /\ \| | | _|    | |  |_ \  / /\ \|  _/  _/
#   \___|_|_\___|_/‾‾\_\_| |___|   |_| |___/ /_/‾‾\_\_| |_|
# 
# 
# ? What will your project be called? t3-siwe
# ? Will you be using TypeScript or JavaScript? TypeScript
# Good choice! Using TypeScript!
# ? Which packages would you like to enable? nextAuth, prisma, tailwind, trpc
# ? Initialize a new git repository? Yes
# Nice one! Initializing repository!
# ? Would you like us to run 'pnpm install'? Yes
# Alright. We'll install the dependencies for you!
# ? What import alias would you like configured? ~/
# 
# Using: pnpm
# 
# ✔ t3-siwe-wip scaffolded successfully!
# Adding boilerplate...
# ✔ Successfully setup boilerplate for nextAuth
# ✔ Successfully setup boilerplate for prisma
# ✔ Successfully setup boilerplate for tailwind
# ✔ Successfully setup boilerplate for trpc
# ✔ Successfully setup boilerplate for envVariables
#
# Installing dependencies...
# ✔ Successfully installed dependencies!
#
# Initializing Git...
# ✔ Successfully initialized and staged git
# 
# Next steps:
#  cd t3-siwe
#  pnpm prisma db push
#  pnpm dev

One of the options we selected is Prisma, so we’ll need to initiate the database. We’ll use the default db.sqlite set int he .env file.

cd t3-siwe;
npx prisma migrate dev;

# Expected Output:
# Environment variables loaded from .env
# Prisma schema loaded from prisma/schema.prisma
# Datasource "db": SQLite database "db.sqlite" at "file:./db.sqlite"
# 
# ? Enter a name for the new migration: › create_new_example_account_session_user_verificationtoken
# Applying migration `20230408143224_create_new_example_account_session_user_verificationtoken`
#
# The following migration(s) have been created and applied from new schema changes:
# 
# migrations/
#   └─ 20230408143224_create_new_example_account_session_user_verificationtoken/
#     └─ migration.sql
# 
# Your database is now in sync with your schema.
# 
# ✔ Generated Prisma Client (4.11.0 | library) to ./node_modules/.pnpm/@prisma+client@4.11.0_prisma@4.11.0/node_modules
# /@prisma/client in 611ms

In a new Terminal, let’s take a look at our new database.

# FROM: ./t3-siwe

npx prisma studio;

# Expected Output:
# Environment variables loaded from .env
# Prisma schema loaded from prisma/schema.prisma
# Prisma Studio is up on http://localhost:5555

Prisma Studio http://localhost:5555

Now that we have our database set up, let’s start the stack and see what it looks like.

# FROM: ./t3-siwe

pnpm dev;

# Expected Output:
# > t3-siwe-wip@0.1.0 dev /Users/username/path/to/t3-siwe-wip
# > next dev
# 
# ready - started server on 0.0.0.0:3000, url: http://localhost:3000

Create T3 App — http://localhost:3000

You’ll notice if we click the Sign in button, we’ll be prompted to a screen that comes with the default Sign in with Discord.

We’re going to replace this functionality.

Adding Connect With Wallet Functionality

To start, we’re going to first establish if the user has connected to the site in order to be prompted to sign the message needed for Sign-In With Ethereum.

For this we’ll need to install some dependencies first.

# FROM: ./t3-siwe

pnpm add wagmi siwe ethers@^5;

With the dependencies, we need to configure Wagmi as provider for our entire app.

File: ./src/pages/_app.tsx

// Imports
// ========================================================
import { type AppType } from "next/app";
import { type Session } from "next-auth";
import { SessionProvider } from "next-auth/react";
import { api } from "~/utils/api";
import "~/styles/globals.css";
// SIWE Integration
import { WagmiConfig, createClient, configureChains } from "wagmi";
import { mainnet, polygon, optimism, arbitrum } from "wagmi/chains";
import { publicProvider } from "wagmi/providers/public";

// Config
// ========================================================
/**
 * Configure chains supported
 */
const { provider } = configureChains(
  [mainnet, polygon, optimism, arbitrum],
  [publicProvider()]
);

/**
 * Configure client with providers and allow for auto wallet connection
 */
const client = createClient({
  autoConnect: true,
  provider,
});

// App Wrapper Component
// ========================================================
const MyApp: AppType<{ session: Session | null }> = ({
  Component,
  pageProps: { session, ...pageProps },
}) => {
  return (
    
      
        
      
    
  );
};

// Exports
// ========================================================
export default api.withTRPC(MyApp);

With the configuration done, we can now modify our main home page to allow the user to connect their wallet to the website. This will show when the wallet has been connected and allows the user to also disconnect.

File: ./src/pages/index.tsx

// Imports
// ========================================================
import { type NextPage } from "next";
import Head from "next/head";
import Link from "next/link";
// (Will add back)
// import { signIn, signOut, useSession } from "next-auth/react";
import { api } from "~/utils/api";
// SIWE Integration
import { useAccount, useConnect, useDisconnect } from "wagmi";
import { InjectedConnector } from 'wagmi/connectors/injected';

// Auth Component
// ========================================================
const AuthShowcase: React.FC = () => {
  // Hooks
  // (Will add back)
  // const { data: sessionData } = useSession();
  // const { data: secretMessage } = api.example.getSecretMessage.useQuery(
  //   undefined, // no input
  //   { enabled: sessionData?.user !== undefined },
  // );

  // Wagmi Hooks
  const { address, isConnected } = useAccount();
  const { connect } = useConnect({
    connector: new InjectedConnector(),
  });
  const { disconnect } = useDisconnect();

  // Render
  return (
    
      
        {address
          ? 
            {address}
          

          : null
        }
                  className="rounded-full bg-white/10 px-10 py-3 font-semibold text-white no-underline transition hover:bg-white/20"
          onClick={() => !isConnected ? connect() : disconnect()}
        >
          {!isConnected ? 'Connect Wallet' : 'Disconnect'}
        
      

    

  );
};

// Page Component
// ========================================================
const Home: NextPage = () => {
  // Requests
  const hello = api.example.hello.useQuery({ text: "from tRPC" });

  // Render
  return (
    <>
      
        Create T3 App
        
        
      
      
        
          
            Create T3 App
          

          
                          className="flex max-w-xs flex-col gap-4 rounded-xl bg-white/10 p-4 text-white hover:bg-white/20"
              href="https://create.t3.gg/en/usage/first-steps"
              target="_blank"
            >
              First Steps →

              
                Just the basics - Everything you need to know to set up your
                database and authentication.
              

            
                          className="flex max-w-xs flex-col gap-4 rounded-xl bg-white/10 p-4 text-white hover:bg-white/20"
              href="https://create.t3.gg/en/introduction"
              target="_blank"
            >
              Documentation →

              
                Learn more about Create T3 App, the libraries it uses, and how
                to deploy it.
              

            
          

          
            
              {hello.data ? hello.data.greeting : "Loading tRPC query..."}
            

            
          

        

      

    
  );
};

// Exports
// ========================================================
export default Home;

Create T3 App Wallet Connection

This looks like a good start until you hard refresh the site and see an error.

Create T3 App NextJS Hydration Error

We’re going to implement a quick fix for this, but if you want to know more about this issue, check out my other article Understanding Hydration Errors In NextJS 13 With A Web3 Wallet Connection.

File: ./src/pages/index.tsx

// Imports
// ========================================================
import { type NextPage } from "next";
import Head from "next/head";
import Link from "next/link";
import { useEffect, useState } from "react";
// (Will add back)
// import { signIn, signOut, useSession } from "next-auth/react";
import { api } from "~/utils/api";
// SIWE Integration
import { useAccount, useConnect, useDisconnect } from "wagmi";
import { InjectedConnector } from 'wagmi/connectors/injected';

// Auth Component
// ========================================================
const AuthShowcase: React.FC = () => {
  // Hooks
  // (Will add back)
  // const { data: sessionData } = useSession();
  // const { data: secretMessage } = api.example.getSecretMessage.useQuery(
  //   undefined, // no input
  //   { enabled: sessionData?.user !== undefined },
  // );
  // State
  const [showConnection, setShowConnection] = useState(false);

  // Wagmi Hooks
  const { address, isConnected } = useAccount();
  const { connect } = useConnect({
    connector: new InjectedConnector(),
  });
  const { disconnect } = useDisconnect();

  // Hooks
  /**
   * Handles hydration issue
   * only show after the window has finished loading
   */
  useEffect(() => {
    setShowConnection(true);
  }, []);

  // Render
  return (
    
      {showConnection
        ? 
          {address
            ? 
              {address}
            

            : null
          }
                      className="rounded-full bg-white/10 px-10 py-3 font-semibold text-white no-underline transition hover:bg-white/20"
            onClick={() => !isConnected ? connect() : disconnect()}
          >
            {!isConnected ? 'Connect Wallet' : 'Disconnect'}
          
        

        : null}
    

  );
};

// Page Component
// ========================================================
// ...

SIWE Next Auth Provider Configuration

For this next part, we need to setup the correct Authentication Provider for NextAuthJS (AuthJS), but in order for things to work, we need to make sure we have a specific version of next-auth installed, as there is currently an issue.

# FROM: ./t3-siwe

pnpm add next-auth@4.20.1;

Once we have that installed, we’re going to configure our authOptions for the Authentication Provider. This is the main configuration for NextAuth that we’re going to leverage with its existing convention for configuration.

File: ./src/server/auth.ts

// Imports
// ========================================================
import { type GetServerSidePropsContext } from "next";
import { getServerSession, type NextAuthOptions, type DefaultSession } from "next-auth";
// (Will add back)
// import { prisma } from "~/server/db";
// SIWE Integration
import type { CtxOrReq } from "next-auth/client/_utils";
import CredentialsProvider from "next-auth/providers/credentials";
import { SiweMessage } from "siwe";
import { getCsrfToken } from "next-auth/react";

// Types
// ========================================================
/**
 * Module augmentation for `next-auth` types. Allows us to add custom properties to the `session`
 * object and keep type safety.
 *
 * @see https://next-auth.js.org/getting-started/typescript#module-augmentation
 */
declare module "next-auth" {
  interface Session extends DefaultSession {
    user: {
      id: string;
      // ...other properties
      // role: UserRole;
    } & DefaultSession["user"];
  }

  // interface User {
  //   // ...other properties
  //   // role: UserRole;
  // }
}

// Auth Options
// ========================================================
/**
 * Options for NextAuth.js used to configure adapters, providers, callbacks, etc.
 *
 * @see https://next-auth.js.org/configuration/options
 */
export const authOptions: (ctxReq: CtxOrReq) => NextAuthOptions = ({ req }) => ({
  callbacks: {
    // token.sub will refer to the id of the wallet address
    session: ({ session, token }) => ({
      ...session,
      user: {
        ...session.user,
        id: token.sub,
      },
    } as Session & { user: { id: string; }}),
    // OTHER CALLBACKS to take advantage of but not needed
    // signIn: async (params: { // Used to control if a user is allowed to sign in
    //   user: User | AdapterUser
    //   account: Account | null
    //   // Not used for credentials
    //   profile?: Profile
    //   // Not user
    //   email?: {
    //     verificationRequest?: boolean
    //   }
    //   /** If Credentials provider is used, it contains the user credentials */
    //   credentials?: Record
    // }) => { return true; },
    // redirect: async (params: { // Used for a callback url but not used with credentials
    //   /** URL provided as callback URL by the client */
    //   url: string
    //   /** Default base URL of site (can be used as fallback) */
    //   baseUrl: string
    // }) => {
    //    return params.baseUrl;
    // },
    // jwt: async ( // Callback whenever JWT created (i.e. at sign in)
    //   params: {
    //     token: JWT
    //     user: User | AdapterUser
    //     account: Account | null
    //     profile?: Profile
    //     trigger?: "signIn" | "signUp" | "update"
    //     /** @deprecated use `trigger === "signUp"` instead */
    //     isNewUser?: boolean
    //     session?: any
    //   }
    // ) => {
    //   return params.token;
    // }
  },
  // OTHER OPTIONS (not needed)
  // secret: process.env.NEXTAUTH_SECRET, // in case you want pass this along for other functionality
  // adapter: PrismaAdapter(prisma), // Not meant for type 'credentials' (used for db sessions)
  // jwt: { // Custom functionlaity for jwt encoding/decoding
  //   encode: async ({ token, secret, maxAge }: JWTEncodeParams) => {
  //     return encode({
  //       token,
  //       secret,
  //       maxAge,
  //     })
  //   },
  //   decode: async ({ token, secret }: JWTDecodeParams) => {
  //     return decode({ token, secret })
  //   }
  // },
  // session: { // Credentials defaults to this strategy
  //   strategy: 'jwt',
  //   maxAge: 2592000,
  //   updateAge: 86400,
  //   generateSessionToken: () => 'SomeValue'
  // },
  // events: { // Callback events
  //   signIn: async (message: {
  //     user: User
  //     account: Account | null
  //     profile?: Profile
  //     isNewUser?: boolean
  //   }) => {},
  //   signOut: async (message: { session: Session; token: JWT }) => {},
  //   createUser:  async (message: { user: User }) => {},
  //   updateUser:  async (message: { user: User }) => {},
  //   linkAccount: async (message: {
  //     user: User | AdapterUser
  //     account: Account
  //     profile: User | AdapterUser
  //   }) => {},
  //   session: async (message: { session: Session; token: JWT }) => {}
  // },
  providers: [
    CredentialsProvider({
      // ! Don't add this
      // - it will assume more than one auth provider 
      // - and redirect to a sign-in page meant for oauth
      // - id: 'siwe', 
      name: "Ethereum",
      type: "credentials", // default for Credentials
      // Default values if it was a form
      credentials: {
        message: {
          label: "Message",
          type: "text",
          placeholder: "0x0",
        },
        signature: {
          label: "Signature",
          type: "text",
          placeholder: "0x0",
        },
      },
      authorize: async (credentials) => {
        try {
          const siwe = new SiweMessage(JSON.parse(credentials?.message as string ?? "{}") as Partial);
          const nonce = await getCsrfToken({ req });
          const fields = await siwe.validate(credentials?.signature || "")

          if (fields.nonce !== nonce) {
            return null;
          }
          return {
            id: fields.address
          };
        } catch (error) {
          // Uncomment or add logging if needed
          console.error({ error });
          return null;
        }
      },
    })
    /**
     * ...add more providers here.
     *
     * Most other providers require a bit more work than the Discord provider. For example, the
     * GitHub provider requires you to add the `refresh_token_expires_in` field to the Account
     * model. Refer to the NextAuth.js docs for the provider you want to use. Example:
     *
     * @see https://next-auth.js.org/providers/github
     */
  ],
});

// Auth Session
// ========================================================
/**
 * Wrapper for `getServerSession` so that you don't need to import the `authOptions` in every file.
 *
 * @see https://next-auth.js.org/configuration/nextjs
 */
export const getServerAuthSession = async (ctx: {
  req: GetServerSidePropsContext["req"];
  res: GetServerSidePropsContext["res"];
}) => {
  // Changed from authOptions to authOption(ctx)
  // This allows use to retrieve the csrf token to verify as the nonce
  return getServerSession(ctx.req, ctx.res, authOptions(ctx));
};

Now that we have our authOptions configured, we need to configure nextAuth to work with this as it differs from what was before because we need to pass it a request.

File: ./src/pages/api/auth/[...nextauth].ts

// Imports
// ========================================================
import { NextApiRequest, NextApiResponse } from "next";
import NextAuth from "next-auth";
import { authOptions } from "~/server/auth";

// Auth
// ========================================================
const Auth = (req: NextApiRequest, res: NextApiResponse) => {
    const authOpts = authOptions({ req });
    return NextAuth(req, res, authOpts);
};

// Exports
// ========================================================
export default Auth;

We have our NextAuth configured, except what you’ll notice is if we go to /api/auth/signin we have a configured Sign in with Ethereum button, but this won’t work with the app, because this is configured to work as a form submission, and the wallet configuration works different.

http://localhost:3000/api/auth/signin

To fix this, we’re just going to account for this by catch if this is the signin page and removing the Credentials Auth Provider.

File: ./src/pages/api/auth/[...nextauth].ts

// Imports
// ========================================================
import { NextApiRequest, NextApiResponse } from "next";
import NextAuth from "next-auth";
import { authOptions } from "~/server/auth";

// Auth
// ========================================================
const Auth = (req: NextApiRequest, res: NextApiResponse) => {
    const authOpts = authOptions({ req });

    const isDefaultSigninPage = req.method === "GET" && req?.query?.nextauth?.includes("signin");

    // Hide Sign-In with Ethereum from default sign page
    if (isDefaultSigninPage) {
        // Removes from the authOptions.providers array
        authOpts.providers.pop();
    }

    return NextAuth(req, res, authOpts);
};

// Exports
// ========================================================
export default Auth;

http://localhost:3000/api/auth/signin

There is probably a more elegant solution for this, but ideally we just discourage the user from going to this link for any sort of authentication flow.

SIWE Authentication & Session Verification

Now that we have the configuration set up, we just need to alter our main home page to allow the user to sign a message which will be verified on our backend and create a session.

File: ./src/pages/index.tsx

// Imports
// ========================================================
import { type NextPage } from "next";
import Head from "next/head";
import Link from "next/link";
import { useEffect, useState } from "react";
import { getCsrfToken, signIn, signOut, useSession } from "next-auth/react";
import { api } from "~/utils/api";
// SIWE Integration
import { SiweMessage } from "siwe";
import { useAccount, useConnect, useDisconnect, useSignMessage, useNetwork } from "wagmi";
import { InjectedConnector } from 'wagmi/connectors/injected';

// Auth Component
// ========================================================
const AuthShowcase: React.FC = () => {
  // Hooks
  const { data: sessionData } = useSession();
  const { data: secretMessage } = api.example.getSecretMessage.useQuery(
    undefined, // no input
    { enabled: sessionData?.user !== undefined },
  );
  // State
  const [showConnection, setShowConnection] = useState(false);

  // Wagmi Hooks
  const { signMessageAsync } = useSignMessage();
  const { address, isConnected } = useAccount();
  const { connect } = useConnect({
    connector: new InjectedConnector(),
  });
  const { disconnect } = useDisconnect();
  const { chain } = useNetwork();

  // Functions
  /**
   * Attempts SIWE and establish session
   */
  const onClickSignIn = async () => {
    try {
      const message = new SiweMessage({
        domain: window.location.host,
        address: address,
        statement: "Sign in with Ethereum to the app.",
        uri: window.location.origin,
        version: "1",
        chainId: chain?.id,
        // nonce is used from CSRF token
        nonce: await getCsrfToken(),
      })
      const signature = await signMessageAsync({
        message: message.prepareMessage(),
      })
      signIn("credentials", {
        message: JSON.stringify(message),
        redirect: false,
        signature,
      })
    } catch (error) {
      window.alert(error);
    }
  };

  /**
   * Sign user out
   */
  const onClickSignOut = async () => {
    await signOut();
  };

  // Hooks
  /**
   * Handles hydration issue
   * only show after the window has finished loading
   */
  useEffect(() => {
    setShowConnection(true);
  }, []);

  // Render
  return (
    
        {sessionData
          ? 
            {sessionData ? 
              Logged in as
              {JSON.stringify(sessionData)}
            
: null}
            {secretMessage ? 
              Secret Message
              {secretMessage}
            
: null}

                          className="rounded-full bg-white/10 px-10 py-3 font-semibold text-white no-underline transition hover:bg-white/20"
              onClick={onClickSignOut as () => void}
            >
              Sign Out
            
          

          : showConnection
            ? 
              {isConnected
                ?                   className="rounded-full bg-white/10 px-10 py-3 font-semibold text-white no-underline transition hover:bg-white/20"
                  onClick={onClickSignIn as () => void}
                >
                  Sign In
                
                : null
              }
            

            : null
        }
      {showConnection
        ? 
          {address
            ? 
              {address}
            

            : null
          }
                      className="rounded-full bg-white/10 px-10 py-3 font-semibold text-white no-underline transition hover:bg-white/20"
            onClick={() => !isConnected ? connect() : disconnect()}
          >
            {!isConnected ? 'Connect Wallet' : 'Disconnect'}
          
        

        : null}
    

  );
};

// Page Component
// ========================================================
// ...

If we try the app, we can see we can connect our wallet, get a prompt for SIWE, and then successfully sign in to see the user session data.

Create T3 App SIWE Prompt

Create T3 App SIWE Session Data Shown

There are just two issues. If we refresh the page, we’ll see that our session is gone, and even when we are signed in, we aren’t seeing our secretMessage which shows when there is session data established.

To fix this, we just need to modify our .env file to add a NEXTAUTH_SECRET.

File: ./.env

# When adding additional environment variables, the schema in "/src/env.mjs"
# should be updated accordingly.

# Prisma
# https://www.prisma.io/docs/reference/database-reference/connection-urls#env
DATABASE_URL="file:./db.sqlite"

# Next Auth
# You can generate a new secret on the command line with:
# openssl rand -base64 32
# https://next-auth.js.org/configuration/options#secret
NEXTAUTH_SECRET="A-REALLY-LONG-SECRET-PASSWORD-32"
NEXTAUTH_URL="http://localhost:3000"

# Next Auth Discord Provider
DISCORD_CLIENT_ID=""
DISCORD_CLIENT_SECRET=""

If we restart our server, and go through the authentication process, we should the secret message now. We should also see our session persist if we refresh the page as well.

Create T3 App SIWE Successful Session Established

If you’re happy with establishing a session with Sign-In With Ethereum, then we got everything covered, but I’d like to take it a step further and get things working on a protected page and configuring our database to store our user’s data.

Modifying Our Database For SIWE

The next thing I want to do is modify the templated database to allow for a wallet address.

If we look at our schema.prisma file we’ll notice we’re not really use the tables for VerificationToken, Session, and Example. These are there mainly to work with database sessions, which we aren’t using.

I’m going to remove some tables, rewrite the Example as a new Todo table, and just add a new address field for the User table.

File: ./prisma/schema.prisma

// This is your Prisma schema file,
// learn more about it in the docs: https://pris.ly/d/prisma-schema

generator client {
    provider = "prisma-client-js"
}

datasource db {
    provider = "sqlite"
    // NOTE: When using postgresql, mysql or sqlserver, uncomment the @db.Text annotations in model Account below
    // Further reading:
    // https://next-auth.js.org/adapters/prisma#create-the-prisma-schema
    // https://www.prisma.io/docs/reference/api-reference/prisma-schema-reference#string
    url      = env("DATABASE_URL")
}

// Revised Example table
model Todo {
    id        String   @id @default(cuid())
    task    String
    userId            String
    completed   Boolean @default(false)
    createdAt DateTime @default(now())
    updatedAt DateTime @updatedAt
    user              User    @relation(fields: [userId], references: [id], onDelete: Cascade)
}

// Necessary for Next auth
model Account {
    id                String  @id @default(cuid())
    userId            String
    type              String
    provider          String
    providerAccountId String
    refresh_token     String? // @db.Text
    access_token      String? // @db.Text
    expires_at        Int?
    token_type        String?
    scope             String?
    id_token          String? // @db.Text
    session_state     String?
    user              User    @relation(fields: [userId], references: [id], onDelete: Cascade)

    @@unique([provider, providerAccountId])
}
model User {
    id            String    @id @default(cuid())
    name          String?
    // New address
    address         String?   @unique
    email         String?   @unique
    emailVerified DateTime?
    image         String?
    accounts      Account[]
    todos   Todo[]
}

With that modification done, let’s run a migration.

# FROM: ./t3-siwe

npx prisma migrate dev;

# Expected Output:
# ✔ Are you sure you want create and apply this migration? … yes
# ✔ Enter a name for the new migration: … create_siwe_structure
# Applying migration `20230409205305_create_siwe_structure`
#
# The following migration(s) have been created and applied from new schema changes:
# 
# migrations/
#   └─ 20230409205305_create_siwe_structure/
#     └─ migration.sql
#
# Your database is now in sync with your schema.
# 
# ✔ Generated Prisma Client (4.11.0 | library) to 
# ./node_modules/.pnpm/@prisma+client@4.11.0_prisma@4.11
# .0/node_modules/@prisma/client in 71ms

Let’s also check on our prisma studio to see the changes.

# FROM: ./t3-siwe

npx prisma studio;

# Expected Output:
# Environment variables loaded from .env
# Prisma schema loaded from prisma/schema.prisma
# Prisma Studio is up on http://localhost:5555

Prisma Studio http://localhost:5555 Updated With Database Changes

New User & Account Creation On NextAuth Authentication

Now that we have the database configured, let’s get our nextOptions configured so that the callback will create a new user if needed, or retrieve an existing user. For the changes, see the authorize section along side adding back the prisma import at the top.

File: ./src/server/auth.ts

// Imports
// ========================================================
import { type GetServerSidePropsContext } from "next";
import { getServerSession, type NextAuthOptions, type DefaultSession } from "next-auth";
import { prisma } from "~/server/db";
// SIWE Integration
import type { CtxOrReq } from "next-auth/client/_utils";
import CredentialsProvider from "next-auth/providers/credentials";
import { SiweMessage } from "siwe";
import { getCsrfToken } from "next-auth/react";

// Types
// ========================================================
/**
 * Module augmentation for `next-auth` types. Allows us to add custom properties to the `session`
 * object and keep type safety.
 *
 * @see https://next-auth.js.org/getting-started/typescript#module-augmentation
 */
declare module "next-auth" {
  interface Session extends DefaultSession {
    user: {
      id: string;
      // ...other properties
      // role: UserRole;
    } & DefaultSession["user"];
  }

  // interface User {
  //   // ...other properties
  //   // role: UserRole;
  // }
}

// Auth Options
// ========================================================
/**
 * Options for NextAuth.js used to configure adapters, providers, callbacks, etc.
 *
 * @see https://next-auth.js.org/configuration/options
 */
export const authOptions: (ctxReq: CtxOrReq) => NextAuthOptions = ({ req }) => ({
  callbacks: {
    // token.sub will refer to the id of the wallet address
    session: ({ session, token }) => ({
      ...session,
      user: {
        ...session.user,
        id: token.sub,
      },
    } as Session & { user: { id: string; }}),
    // OTHER CALLBACKS to take advantage of but not needed
    // signIn: async (params: { // Used to control if a user is allowed to sign in
    //   user: User | AdapterUser
    //   account: Account | null
    //   // Not used for credentials
    //   profile?: Profile
    //   // Not user
    //   email?: {
    //     verificationRequest?: boolean
    //   }
    //   /** If Credentials provider is used, it contains the user credentials */
    //   credentials?: Record
    // }) => { return true; },
    // redirect: async (params: { // Used for a callback url but not used with credentials
    //   /** URL provided as callback URL by the client */
    //   url: string
    //   /** Default base URL of site (can be used as fallback) */
    //   baseUrl: string
    // }) => {
    //    return params.baseUrl;
    // },
    // jwt: async ( // Callback whenever JWT created (i.e. at sign in)
    //   params: {
    //     token: JWT
    //     user: User | AdapterUser
    //     account: Account | null
    //     profile?: Profile
    //     trigger?: "signIn" | "signUp" | "update"
    //     /** @deprecated use `trigger === "signUp"` instead */
    //     isNewUser?: boolean
    //     session?: any
    //   }
    // ) => {
    //   return params.token;
    // }
  },
  // OTHER OPTIONS (not needed)
  // secret: process.env.NEXTAUTH_SECRET, // in case you want pass this along for other functionality
  // adapter: PrismaAdapter(prisma), // Not meant for type 'credentials' (used for db sessions)
  // jwt: { // Custom functionlaity for jwt encoding/decoding
  //   encode: async ({ token, secret, maxAge }: JWTEncodeParams) => {
  //     return encode({
  //       token,
  //       secret,
  //       maxAge,
  //     })
  //   },
  //   decode: async ({ token, secret }: JWTDecodeParams) => {
  //     return decode({ token, secret })
  //   }
  // },
  // session: { // Credentials defaults to this strategy
  //   strategy: 'jwt',
  //   maxAge: 2592000,
  //   updateAge: 86400,
  //   generateSessionToken: () => 'SomeValue'
  // },
  // events: { // Callback events
  //   signIn: async (message: {
  //     user: User
  //     account: Account | null
  //     profile?: Profile
  //     isNewUser?: boolean
  //   }) => {},
  //   signOut: async (message: { session: Session; token: JWT }) => {},
  //   createUser:  async (message: { user: User }) => {},
  //   updateUser:  async (message: { user: User }) => {},
  //   linkAccount: async (message: {
  //     user: User | AdapterUser
  //     account: Account
  //     profile: User | AdapterUser
  //   }) => {},
  //   session: async (message: { session: Session; token: JWT }) => {}
  // },
  providers: [
    CredentialsProvider({
      // ! Don't add this
      // - it will assume more than one auth provider 
      // - and redirect to a sign-in page meant for oauth
      // - id: 'siwe', 
      name: "Ethereum",
      type: "credentials", // default for Credentials
      // Default values if it was a form
      credentials: {
        message: {
          label: "Message",
          type: "text",
          placeholder: "0x0",
        },
        signature: {
          label: "Signature",
          type: "text",
          placeholder: "0x0",
        },
      },
      authorize: async (credentials) => {
        try {
          const siwe = new SiweMessage(JSON.parse(credentials?.message as string ?? "{}") as Partial);
          const nonce = await getCsrfToken({ req });
          const fields = await siwe.validate(credentials?.signature || "")

          if (fields.nonce !== nonce) {
            return null;
          }

          // Check if user exists
          let user = await prisma.user.findUnique({
            where: {
              address: fields.address
            }
          });
          // Create new user if doesn't exist
          if (!user) {
            user = await prisma.user.create({
              data: {
                address: fields.address
              }
            });
            // create account
            await prisma.account.create({
              data: {
                userId: user.id,
                type: "credentials",
                provider: "Ethereum",
                providerAccountId: fields.address
              }
            });
          }

          return {
            // Pass user id instead of address
            // id: fields.address
            id: user.id
          };
        } catch (error) {
          // Uncomment or add logging if needed
          console.error({ error });
          return null;
        }
      },
    })
    /**
     * ...add more providers here.
     *
     * Most other providers require a bit more work than the Discord provider. For example, the
     * GitHub provider requires you to add the `refresh_token_expires_in` field to the Account
     * model. Refer to the NextAuth.js docs for the provider you want to use. Example:
     *
     * @see https://next-auth.js.org/providers/github
     */
  ],
});

// Auth Session
// ========================================================
// ...

Restart the server, sign out, and sign back in. We should now see the user id in the session data, instead of our wallet address.

Create T3 App Session User Id

We should also see in our database that the new user has been created.

Prisma Studio New User Created

Creating Todos TRPC Requests

In order to support the creationg and modification of our new Todo table, we’ll create a todosRouter for trpc that has basic CRUD as all, add, remove, and update.

File: ./src/server/api/routers/todos.ts

// Imports
// ========================================================
import { z } from "zod";
import { createTRPCRouter, protectedProcedure } from "~/server/api/trpc";

// Router
// ========================================================
export const todosRouter = createTRPCRouter({
  /**
   * All todos belonging to the session user
   */
  all: protectedProcedure.query(async ({ ctx }) => {
    const todos = await ctx.prisma.todo.findMany({
      where: {
        userId: ctx.session.user.id
      }
    });
    return todos;
  }),
  /**
   * Add todo belonging to the session user
   */
  add: protectedProcedure
    .input(z.object({ task: z.string() }))
    .mutation(async ({ input, ctx }) => {
      return await ctx.prisma.todo.create({
        data: {
          task: input.task,
          userId: ctx.session.user.id
        }
      })
    }),
  /**
   * Remove todo belonging to the session user* 
   */
  remove: protectedProcedure
    .input(z.object({ id: z.string() }))
    .mutation(async ({ input, ctx }) => {
      return await ctx.prisma.todo.deleteMany({
        where: {
          id: input.id,
          userId: ctx.session.user.id
        }
      })
    }),
  /**
   * Update todo belonging to the session user
   */
  update: protectedProcedure
    .input(z.object({ 
      id: z.string(), 
      task: z.string().optional(),
      completed: z.boolean().optional()
    }))
    .mutation(async ({ input, ctx }) => {
      console.log({ input });
      const data: { task?: string, completed?: boolean } = {};
      if (input.task) {
        data.task = input.task;
      }
      if (typeof input.completed !== "undefined") {
        data.completed = input.completed;
      }

      return await ctx.prisma.todo.updateMany({
        data,
        where: {
          id: input.id,
          userId: ctx.session.user.id
        }
      });
    })
});

Next I want to modify our root file to add the router to trpc.

File: ./src/server/api/root.ts

import { createTRPCRouter } from "~/server/api/trpc";
import { exampleRouter } from "~/server/api/routers/example";
import { todosRouter } from "~/server/api/routers/todos";

/**
 * This is the primary router for your server.
 *
 * All routers added in /api/routers should be manually added here.
 */
export const appRouter = createTRPCRouter({
  example: exampleRouter,
  todos: todosRouter
});

// export type definition of API
export type AppRouter = typeof appRouter;

We also need to make a modification to our previous example.ts file as we changed our Example table to Todo now.

File: ./src/server/api/routers/example.ts

// Imports
// ========================================================
import { z } from "zod";
import {
  createTRPCRouter,
  publicProcedure,
  protectedProcedure,
} from "~/server/api/trpc";

// Router
// ========================================================
export const exampleRouter = createTRPCRouter({
  hello: publicProcedure
    .input(z.object({ text: z.string() }))
    .query(({ input }) => {
      return {
        greeting: `Hello ${input.text}`,
      };
    }),
  getSecretMessage: protectedProcedure.query(() => {
    return "you can now see this secret message!";
  }),
});

New Protected Todo Page With Session Support

With the trpc request built and the user data being stored in the database, we can now create a page that is protected if the user isn’t signed in, and shows their todos if they are.

# FROM: ./t3-siwe

touch ./src/pages/todos.tsx;

If we paste the following code, we should see the functionality for the session access required and the user todo trpc requests.

File: ./src/pages/todos.tsx

// Imports
// ========================================================
import { type NextPage } from "next";
import Link from "next/link";
import { useSession } from "next-auth/react";
import { api } from "~/utils/api";
import { useEffect, useState } from "react";

// Page Component
// ========================================================
const Todos: NextPage = () => {
  // State / Props / Hooks
  const { data: sessionData } = useSession();
  const [todos, setTodos] = useState<{ task: string; id: string; completed: boolean; }[]>([]);
  const [newTodo, setNewTodo] = useState('');

  // Requests
  // - All
  const {
    data: todosAllData,
    isLoading: todosAllIsLoading,
    refetch: todosAllRefetch
  } = api.todos.all.useQuery(
    undefined, // no input
    {
      // Disable request if no session data
      enabled: sessionData?.user !== undefined,
      onSuccess: () => {
        setNewTodo(''); // reset input form
      }
    },
  );
  // - Add
  const {
    mutate: todosAddMutate,
    isLoading: todosAddIsLoading,
  } = api.todos.add.useMutation({
    onSuccess: async () => {
      await todosAllRefetch();
    }
  });
  // - Remove
  const {
    mutate: todosRemoveMutate,
    isLoading: todosRemoveIsLoading,
  } = api.todos.remove.useMutation({
    onSuccess: async () => {
      await todosAllRefetch();
    }
  });
  // - Update
  const {
    mutate: todosUpdateMutate,
    isLoading: todosUpdateIsLoading,
  } = api.todos.update.useMutation({
    onSuccess: async () => {
      await todosAllRefetch();
    }
  });
  // Handle loading for all requests to disable buttons and inputs
  const isRequestLoading = todosAllIsLoading || todosAddIsLoading || todosRemoveIsLoading || todosUpdateIsLoading;

  // Functions
  /**
   * 
   * @param event 
   */
  const onSubmitForm = (event: React.FormEvent) => {
    console.group('onSubmitForm');
    event.preventDefault();

    const formData = new FormData(event.currentTarget);
    const todoValue = formData.get('todo') as string || '';
    console.log({ todoValue });

    todosAddMutate({ task: todoValue });
    console.groupEnd();
  };

  /**
   * 
   * @param id 
   * @returns 
   */
  const onClickToggleDone = (id: string) => () => {
    console.group('onClickToggleDone');
    console.log({ id });

    todosUpdateMutate({
      id,
      completed: !todos.find(i => i.id === id)?.completed
    })
    console.groupEnd();
  };

  /**
   * 
   * @param id 
   * @returns 
   */
  const onClickDelete = (id: string) => () => {
    console.group('onClickDelete');
    console.log({ id });

    todosRemoveMutate({
      id
    });
    console.groupEnd();
  };

  // Hooks
  useEffect(() => {
    console.log({ todosAllData });
    if (todosAllIsLoading) return;
    setTodos(todosAllData || []);
  // eslint-disable-next-line react-hooks/exhaustive-deps
  }, [todosAllData]);

  // When rendering client side don't display anything until loading is complete
  // if (typeof window !== "undefined" && loading) return null
  // If no session exists, display access denied message
  return (
    <>
      
        
          
            {!sessionData ? 'Access Denied' : 'Todos'}
          

        

        
          Home Page
        

        {sessionData ? 
          
            
              New Todo
               setNewTodo(e.target.value)} className="disabled:opacity-30 h-10 bg-white rounded px-4 w-full" type="text" name="todo" value={newTodo} />
            

            
              
            

          

          {todos.length === 0
            ? (No todos yet!)

            : 
              {todos.map((todo, key) => 
                {todo.task}
                
                  
                  
                
              
)}
            

          }
        
 : null}
      

    
  );
};

// Exports
// ========================================================
export default Todos;

We’re also going to make one small modification to our index.tsx to give it a link to the todos page.

File: ./src/pages/index.tsx

// ...

// Page Component
// ========================================================
const Home: NextPage = () => {
  // Requests
  const hello = api.example.hello.useQuery({ text: "from tRPC" });

  // Render
  return (
    <>
      
        Create T3 App SIWE
        
        
      
      
        
          
            Create T3 App SIWE
          

          
                          className="flex max-w-xs flex-col gap-4 rounded-xl bg-white/10 p-4 text-white hover:bg-white/20"
              href="https://create.t3.gg/en/usage/first-steps"
              target="_blank"
            >
              First Steps →

              
                Just the basics - Everything you need to know to set up your
                database and authentication.
              

            
                          className="flex max-w-xs flex-col gap-4 rounded-xl bg-white/10 p-4 text-white hover:bg-white/20"
              href="https://create.t3.gg/en/introduction"
              target="_blank"
            >
              Documentation →

              
                Learn more about Create T3 App, the libraries it uses, and how
                to deploy it.
              

            
          

          
            
              {/* HERE - new todo link */}
              (Protected) Todos Page
            

            
              {hello.data ? hello.data.greeting : "Loading tRPC query..."}
            

            
          

        

      

    
  );
};

// Exports
// ========================================================
export default Home;

Now if we take a look at our full app we should see the home page, access denied if no session to the todo page, and managing todos stored to the database.

Create T3 App With SIWE Not Logged In

Create T3 App With SIWE Todo Page Access Denied With No Session

Create T3 App With SIWE Logged In

Create T3 App With SIWE Todo Page With Todos Stored To The Database

Bonus Blockies Image

One last thing, I’m going to add is support for a blockies image generated by the user’s wallet address.

# FROM: ./t3-siwe

pnpm add @codingwithmanny/blockies; # npm install @codingwithmanny/blockies;

File: ./src/pages/index.tsx

// Imports
// ========================================================
import { type NextPage } from "next";
import Head from "next/head";
import Link from "next/link";
// Add this new package
import Image from "next/image";
import { useEffect, useState } from "react";
import { getCsrfToken, signIn, signOut, useSession } from "next-auth/react";
import { api } from "~/utils/api";
// Add this new package
import { renderDataURI } from "@codingwithmanny/blockies";
// SIWE Integration
import { SiweMessage } from "siwe";
import { useAccount, useConnect, useDisconnect, useSignMessage, useNetwork } from "wagmi";
import { InjectedConnector } from 'wagmi/connectors/injected';

// Auth Component
// ========================================================
const AuthShowcase: React.FC = () => {
  // Hooks
  const { data: sessionData } = useSession();
  const { data: secretMessage } = api.example.getSecretMessage.useQuery(
    undefined, // no input
    { enabled: sessionData?.user !== undefined },
  );
  // State
  const [showConnection, setShowConnection] = useState(false);

  // Wagmi Hooks
  const { signMessageAsync } = useSignMessage();
  const { address, isConnected } = useAccount();
  const { connect } = useConnect({
    connector: new InjectedConnector(),
  });
  const { disconnect } = useDisconnect();
  const { chain } = useNetwork();

  // Functions
  /**
   * Attempts SIWE and establish session
   */
  const onClickSignIn = async () => {
    try {
      const message = new SiweMessage({
        domain: window.location.host,
        address: address,
        statement: "Sign in with Ethereum to the app.",
        uri: window.location.origin,
        version: "1",
        chainId: chain?.id,
        // nonce is used from CSRF token
        nonce: await getCsrfToken(),
      })
      const signature = await signMessageAsync({
        message: message.prepareMessage(),
      })
      await signIn("credentials", {
        message: JSON.stringify(message),
        redirect: false,
        signature,
      });
    } catch (error) {
      window.alert(error);
    }
  };

  /**
   * Sign user out
   */
  const onClickSignOut = async () => {
    await signOut();
  };

  // Hooks
  /**
   * Handles hydration issue
   * only show after the window has finished loading
   */
  useEffect(() => {
    setShowConnection(true);
  }, []);

  // Render
  return (
    
      {sessionData
        ? 
          {sessionData ? 
            Logged in as
            {/* Add this new line */}
            {sessionData?.user?.id ?  : null}
            {JSON.stringify(sessionData)}
          
 : null}
          {secretMessage ? 
            Secret Message
            {secretMessage}
          
 : null}

                      className="rounded-full bg-white/10 px-10 py-3 font-semibold text-white no-underline transition hover:bg-white/20"
            onClick={onClickSignOut as () => void}
          >
            Sign Out
          
        

        : showConnection
          ? 
            {isConnected
              ?                 className="rounded-full bg-white/10 px-10 py-3 font-semibold text-white no-underline transition hover:bg-white/20"
                onClick={onClickSignIn as () => void}
              >
                Sign In
              
              : null
            }
          

          : null
      }
      {showConnection
        ? 
          {address
            ? 
              {address}
            

            : null
          }
                      className="rounded-full bg-white/10 px-10 py-3 font-semibold text-white no-underline transition hover:bg-white/20"
            onClick={() => !isConnected ? connect() : disconnect()}
          >
            {!isConnected ? 'Connect Wallet' : 'Disconnect'}
          
        

        : null}
    

  );
};

// Page Component
// ========================================================
// ...

Create T3 App With SIWE Implementation & Blockies Image

We’ve successfully completed the entire process of adding SIWE with the T3 Stack.

Full Code Repository

If you want to see the final product for the full code repository, check out t3-app-siwe.

GitHub - codingwithmanny/t3-app-siwe: Implementation of Sign-In With Ethereum with Create-T3-Stack including Prisma, tRPC, NextAuth, Tailwind, and TypeScript

What’s Next?

This was a first attempt in trying to get more adoption for developers to start using web3 tools within more traditional web3 stacks, libraries, and frameworks to make it easier to get started.

The goal would be either to build a Auth Provider that works slightly different for wallets and signing messages like Sign-In With Ethereum, and just overall get better adoption for web2 and web3 tools working together.

If you got value from this, please also follow me on twitter (where I’m quite active) @codingwithmanny and instagram at @codingwithmanny.

Oh! I’m also on YouTube now as @codingwithmanny.

The Ultimate ERC1155 Mythic Card NFT Contract Walkthrough On Polygon zkEVM

Manny — Sun, 02 Apr 2023 14:07:46 GMT

Using Midjourney & ChatGPT — How I Created A Mythic Cards NFT Collection On Polygon zkEVM

Build A Mythic NFT Card Collection With ERC1155 On Polygon zkEVM

https://medium.com/media/85efee0139dca9b7ebed87e72a23110b/href

What Is Polygon zkEVM

Polygon zkEVM is the latest network released from Polygon that helps scale Ethereum transactions, at a cheaper cost, and while leveraging the security of Ethereum itself.

What this means for NFT creators is that this is an interesting way to save on costs for transactions, the ability to bridge tokens back and forth (NFTs bridging coming), and taking advantage of native ETH to handle payments through bridging.

Cheaper, faster, and build like you would on Ethereum.

https://polygon.technology/polygon-zkevm

What Is An ERC1155 Contract

An ERC1155 contract is an NFT token that takes the best of ERC20 and ERC721 and allows you to manage multiple tokens that are fungible or non-fungible in one contract.

This functionality is ideal for games that want to integrate some sort of ownership or NFT component for different items that may have multiple owners, for example like have 10 broad swords weapons that have the same attributes but will belong to different people.

Creating Design Assets For Mythic Cards

This article will show you how I created the design graphics with Midjourney, the details and description with ChatGPT, and the card animations. In true NFT fashion I also show you how I uploaded the files to Arweave to make the files more permanent.

If you want to skip the design aspect and go straight into the contract, see the Building An ERC1155 NFT Collection On Polygon zkEVM section.

Midjourney Card Design Prompts

I took a lot of inspiration from the Blizzard game Hearstone to design these items. With Midjourney, I knew that I needed both the items themselves, the surrounding decorative graphic that would make them look consistent, and a standard design for the back of the cards.

Midjourney Item Prompts

I tried a few prompts but the one that seem to work the best was the following:

// an axe with no characters in the photo and just the item iteself, in the style of blizzard heartstone

// OR

// purple fiery dagger with no characters in the photo and just the item itself without any other items, in the style of blizzard heartstone

Midjourney Generating Sword Graphic

Sword, axe, and skull I got to generate had no problem, but Midjourney had an issue with the word Bow (even tried Archery Bow) for a bow and arrow.

Midjourney Difficulty Generating A Bow & Arrow

With the sword, axe, skull, and a heart looking item, I landed on these four items.

Mythic Card Items Generated With Midjourney

Generating Decorations & Card Back

Once I had all four items, I made sure to ask it to generate some random rock formations that I knew I could mold to cover the items. I also made a prompt for some nice wooden doors for the back of the cards.

// a decorative rock background that takes up the entire photo, with no characters in the photo, just the item itself, and without any other items, in the style of blizzard heartstone

Midjourney Generating Rock Formation Image

// a decorative wooden background with no characters in the photo and just the item itself without any other items, facing forward, in the style of blizzard heartstone

Midjourney Generating Wooden Door Image For Back Of Card

Editing Images In Photoshop

The cards weren’t complete, because I still needed to edit them a bit in Photoshop to increase the height I was looking for, creating the decorative border, and adding some slight glows to them.

[GIF] Editing Cards With Photoshop

Final Card Graphics Edited In Photoshop

Creating SVG Card Animation

This took me a bit longer to do because there is this css property called backface-visibility, which unfortunately doesn’t work within SVGs.

In order to get the card animation I wanted, I needed to create a rotating rectangle (later switched for an image), that would rotate up to the point where it was sideways, go completely transparent, and then reappear to complete the full rotation cycle. With two of these rectangles, I could mimic the backface-visibility and make it appear as if the rotation was smoothly transitioning back and forth between the front and back of the card.

Card Animation Iteration 1 — Basic Rotation

Getting the one side of the card to rotate in the middle and go invisible when rotated on its side.

https://medium.com/media/535759cb3be9113ec58088f7f309ffca/href

Card Animation Iteration 2 — Alternating

Getting both the front end back of the card to iterate back and forth between showing and hiding their respective sides.

https://medium.com/media/46aafb13f2d141becdc05edd2bfb46d3/href

Card Animation Iteration 3— Supporting Graphics

Taking advantage of being able to use base64 encoding for image data, we can replace the rect tags with image tags with a href attribute starting with the following:

Using base64.guru we can upload a file and get it to generate the base64 encoding we need for the image.
https://base64.guru/converter/encode/image
https://medium.com/media/14557b591a205a39c76f4c43b5acbccb/hrefCard Animation Iteration 4— Styling
The last step is to get the round edges applied and give it a radial gradient background. Unfortunately there is no easy way to do a rounded border radius with the image tag, so we’ll need to use a clipPath rect applied to both image tags.
https://medium.com/media/7aeb97767cf56ed13e6afea8f562fb14/hrefWith the animation and format done, I can save all 4 items as separate SVG images. We’ll put all four images into an SVG folder.
# ./zkevm-erc1155
# svg
# ├── axe.svg
# ├── heart.svg
# ├── skull.svg
# └── sword.svg
Uploading Our Graphics & Metadata To Arweave Permaweb
Now that we have the images, we need to store these SVG images in a place where we can reference them later for the metadata JSON file that we need for OpenSea and other NFT readers to download and display it correctly.
NOTE: For these next steps, in order to upload we’ll need either real Ethereum ETH or Polygon MATIC in order to upload to Arweave.
Dependency Install & Setup
# FROM: ./zkevm-erc1155

npm init -y;
npm install dotenv @bundlr-network/client bignumber.js; 
npm install -D @types/node ts-node typescript;
./node_modules/.bin/tsc --init;
mkdir upload; # Folder storing our file upload scripts
touch .env;
In our .env file we’ll add the private key of the wallet which has MATIC to pay for the upload.
File: ./.env
WALLET_PRIVATE_KEY=""
Uploading Files To Arweave
In our new upload folder, we’ll create an file uploader that will read the svg folder’s files, estimate their cost, fund a Bundlr node, and upload them to Arweave.
File: ./upload/arweaveFiles.ts
// Imports
// ========================================================
import Bundlr from "@bundlr-network/client";
import fs from "fs";
import path from 'path';
import dotenv from 'dotenv';
import BigNumber from "bignumber.js";

// Config
// ========================================================
dotenv.config();
const ARWEAVE_TX_URL = "https://arweave.net/";
const privateKey = process.env.WALLET_PRIVATE_KEY;
const bundlr = new Bundlr("http://node1.bundlr.network", "matic", privateKey); // NOTE: You need matic in your wallet to upload

// Main Upload Script
// ========================================================
(async () => {
    try {
        // Retrieve current balance
        console.group('Current Balance');
        const atomicBalance = await bundlr.getLoadedBalance();
        console.log({ atomicBalance });
        console.log({ atomicBalance: atomicBalance.toString() });
        const convertedBalance = bundlr.utils.unitConverter(atomicBalance);
        console.log({ convertedBalance });
        console.log({ convertedBalance: convertedBalance.toString() });
        console.groupEnd();

        // Get all files
        console.group('Files');
        const folderPath = path.join(__dirname, '..', 'svg');
        const files = await fs.readdirSync(folderPath);
        console.log({ files });
        const svgFiles = files.filter(i => i.includes('.svg'));
        console.log({ svgFiles });
        console.groupEnd();

        // Get total file size for all files
        console.group('Funding Node');
        let size = 0;
        for (let i = 0; i < svgFiles.length; i++) {
            const fileToUpload = path.join(__dirname, '..', 'svg', svgFiles[i]);
            const fileSize = await fs.statSync(fileToUpload);
            size += fileSize.size;
        }
        console.log({ size });
        const price = await (await bundlr.getPrice(size)).toNumber() / 1000000000000000000;
        console.log({ price });
        
        // Fund if needed
        if (price > parseFloat(convertedBalance.toString())) {
            console.log('Funding...');
            const fundAmountParsed = BigNumber(price as any).multipliedBy(bundlr.currencyConfig.base[1]);
            console.log({ fundAmountParsed: fundAmountParsed.toString() });
            await bundlr.fund(fundAmountParsed.toString());
            const convertedBalance = bundlr.utils.unitConverter(atomicBalance);
            console.log({ convertedBalance: convertedBalance.toString() });
        }
        console.groupEnd();

        console.group('Uploading...');
        for (let i = 0; i < svgFiles.length; i++) {
            const fileToUpload = path.join(__dirname, '..', 'svg', svgFiles[i]);
            const response = await bundlr.uploadFile(fileToUpload);
            console.log(`${ARWEAVE_TX_URL}${response.id}`);
        }
        console.groupEnd();
    } catch (e) {
        console.error("Error uploading file ", e);
    }
})();
We’ll make it slightly easier on ourselves to add the upload command to our package.json.
File: ./package.json
// ...
  "scripts": {
    "uploadFiles": "./node_modules/.bin/ts-node upload/arweaveFiles.ts"
  },
// ...
If we run uploadFiles we should get the following:
# FROM ./zkevm-erc1155

npm run uploadFiles;

# Expected Output:
# Current Balance
#   { atomicBalance: BigNumber { s: 1, e: 15, c: [ 15, 71544535461003 ] } }
#   { atomicBalance: '1571544535461003' }
#   {
#     convertedBalance: BigNumber { s: 1, e: -3, c: [ 157154453546, 10030000000000 ] }
#   }
#   { convertedBalance: '0.001571544535461003' }
# Files
#   { files: [ 'axe.svg', 'heart.svg', 'skull.svg', 'sword.svg' ] }
#   { svgFiles: [ 'axe.svg', 'heart.svg', 'skull.svg', 'sword.svg' ] }
# Funding Node
#   { size: 2550214 }
#   { price: 0.007514900904697801 }
#   Funding...
#   { fundAmountParsed: '7514900904697801' }
#   { convertedBalance: '0.001571544535461003' }
# Uploading...
#   https://arweave.net/JtA8psYtbOP9i3QqxBAnkWVSVbNtL7-F_x-I3JMadE4
#   https://arweave.net/CcNM3Jaq5qAyfmAlUVPFqBEFz51ikZrGYw6cRsqQius
#   https://arweave.net/jFtwyxLxhzbzP94LYl0HcBuODwJsGT7JLdsWxWXhZK8
#   https://arweave.net/mXQ0uptvLKnMCc2LxqGxMwp6He2upfz_AeFV6MEgv8g
NOTE: If the upload fails, there is a good chance that the node for Bundlr hasn’t been fully funded and you may need to adjust the funds that need to be sent in order to pay for the upload.
If we take one of the Arweave links, we can see that our image has been successfully uploaded.
https://arweave.net/JtA8psYtbOP9i3QqxBAnkWVSVbNtL7-F_x-I3JMadE4
Creating NFT Metadata
Now that we have the image urls, we need to create Metadata for each item as a separate JSON file that references the Arweave image. We also need to make sure that each JSON file is stored as the token ID (as an integer) for the filename (Ex: 1.json, 2.json, …).
We’ll store all these JSON files into a folder called manifest and we’ll use ChatGPT to create some descriptions.
ChatGTP Item Description
Do this for all items, and create a JSON file for each in the following JSON format:
File: ./manifest/1.json
{
    "description": "The Blade of Souls is a legendary weapon steeped in mystery and lore. It is said to have been created by the gods themselves, imbued with the power to vanquish even the most malevolent of beings.", 
    "image": "https://arweave.net/h3kkGN_QRfhYWbZlQb5N2bSaqj6HNB4_pGxLfsdhWuo", 
    "name": "Blade Of Souls",
    "attributes": [
        {
            "trait_type": "Damage", 
            "value": 12
        }
    ]
}
In that same folder, we’ll also add a contract.json file with metadata for the contract itself.
File: ./manifest/contract.json
{
    "name": "zkMythicCards",
    "description": "zkMythicCards is a mystical card game played by the gods themselves, where players use their elemental powers to summon creatures and cast spells to defeat their opponents and claim ultimate victory"
}
Uploading Folder To Arweave
With JSON files 1–4 created and referencing their respective items and descriptions, we can now use Arweave to upload the folder so that it references an integer which we can use from our token ID in our ERC1155 contract.
In our upload folder, we’ll create a new file called uploadFolder.ts.
File: ./upload/arweaveFolder.ts
// Imports
// ========================================================
import Bundlr from "@bundlr-network/client";
import fs from "fs";
import path from 'path';
import dotenv from 'dotenv';

// Config
// ========================================================
dotenv.config();
const ARWEAVE_TX_URL = "https://arweave.net/";
const privateKey = process.env.WALLET_PRIVATE_KEY;
const bundlr = new Bundlr("http://node1.bundlr.network", "matic", privateKey);

// Main Upload Script
// ========================================================
(async () => {
    console.group('Uploading folder...');
    try {
        const folderPath = path.join(__dirname, '..', 'manifest');
        const folder = fs.existsSync(folderPath);
        console.log({ folderExists: folder });
        if (!folder) {
            throw new Error('Folder doesn\'t exist');
        }
        const response = await bundlr.uploadFolder(folderPath, {
            indexFile: "", // optional index file (file the user will load when accessing the manifest)
            batchSize: 4, //number of items to upload at once
            keepDeleted: false, // whether to keep now deleted items from previous uploads
        }); //returns the manifest ID
    
        console.log({ response });
        console.log({ URL: `${ARWEAVE_TX_URL}${response?.id}`});
    } catch (e) {
        console.error("Error uploading file ", e);
    }
    console.groupEnd();
})();
We’ll easier on ourselves again by adding the upload command to our package.json.
File: ./package.json
// ...
  "scripts": {
    "uploadFiles": "./node_modules/.bin/ts-node upload/arweaveFiles.ts",
    "uploadFolder": "./node_modules/.bin/ts-node upload/arweaveFolder.ts",
  },
// ...
Now if we run uploadFolder, we should get the following result:
# FROM ./zkevm-erc1155

npm run uploadFolder;

# Expected Output:
# Uploading folder...
#   { folderExists: true }
#   {
#     response: {
#       id: 'l9LANRyWrOOOgnaDrOG8QKBRbxTNf7mMeANw781y4bs',
#       timestamp: 1679943617898
#     }
#   }
#   {
#     URL: 'https://arweave.net/l9LANRyWrOOOgnaDrOG8QKBRbxTNf7mMeANw781y4bs'
#   }
Using the URL, paste it into your browser and append any of the numbers from 1 to 4 or contract as /1.json to it.
https://arweave.net/l9LANRyWrOOOgnaDrOG8QKBRbxTNf7mMeANw781y4bs/4.json
With the URL we’ll also add it to our .env file as the following:
File: ./env
WALLET_PRIVATE_KEY=""
BASE_URL=""
We now have all our design assets and files ready to create the NFT project.
Building An ERC1155 NFT Collection On Polygon zkEVM
The next step is to create our ERC1155 contract with Hardhat, make some custom modifications, and configure it for zkEVM Testnet deployment.
Setting Up Hardhat With ERC1155
Because we’re using npx hardhat to create the template base, we’ll need to remove our previous package.json and add those dependencies and some additional ones again.
# FROM: ./zkevm-erc1155

rm package.json;
rm tsconfig.json;
npx hardhat;

# Expeceted Output:
# ✔ What do you want to do? · Create a TypeScript project
# ✔ Hardhat project root: · /Users/username/path/to/zkevm-erc1155
# ✔ Do you want to add a .gitignore? (Y/n) · y
# ✔ Do you want to install this sample project's dependencies with npm (hardhat @nomicfoundation/hardhat-toolbox)? (Y/n) · y

npm install dotenv @bundlr-network/client bignumber.js @openzeppelin/contracts; 
npm install -D @types/node ts-node typescript;
File: ./package.json
// ...
  "scripts": {
    "uploadFiles": "./node_modules/.bin/ts-node upload/arweaveFiles.ts",
    "uploadFolder": "./node_modules/.bin/ts-node upload/arweaveFolder.ts",
  },
// ...
We’ll rename the template solidity file generated from Hardhat and remove the test folder because they won’t apply to this new contract.
# FROM: ./zkevm-erc1155

mv contracts/Lock.sol contracts/ZkMythicCards.sol;
rm -rf test;
Creating Our ERC1155 Contract
Now that we have what we need, we’ll create our contract with some additional functionality for random number generations (VRF isn’t supported yet for zkEVM) and getting the contract URI for the contract metadata.
File: ./contracts/ZkMythicCards.sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.9;

// Imports
// ========================================================
import "@openzeppelin/contracts/token/ERC1155/ERC1155.sol";
import "@openzeppelin/contracts/access/Ownable.sol";
import "@openzeppelin/contracts/security/Pausable.sol";
import "@openzeppelin/contracts/token/ERC1155/extensions/ERC1155Burnable.sol";
import "@openzeppelin/contracts/token/ERC1155/extensions/ERC1155Supply.sol";
import "@openzeppelin/contracts/utils/Strings.sol";

// Contract
// ========================================================
contract ZkMythicCards is ERC1155, Ownable, Pausable, ERC1155Burnable, ERC1155Supply {
    // Extending functionality
    using Strings for uint256;
    // Used to keep track of a random number generated for selecting one of the four items
    uint256 public randomNumber;

    /**
     * Main constructor seting the the baseURI
     * newuri - sets the base url for where we are storing our manifest JSON files
     */
    constructor(string memory newuri)
        ERC1155(newuri)
    {}

    /**
     * @dev Sets a new URI for all token types, by relying on the token type ID
     */
    function setURI(string memory newuri) public onlyOwner {
        _setURI(newuri);
    }

    /**
     * @dev Triggers stopped state.
     */
    function pause() public onlyOwner {
        _pause();
    }

    /**
     * @dev Returns to normal state.
     */
    function unpause() public onlyOwner {
        _unpause();
    }

    /**
     * @dev Creates random number based on number of loops to generate
     * (This is before VRF is supported on zkEVM)
     */
    function generateRandomNumber(uint256 loopCount) public {
        for (uint256 i = 0; i < loopCount; i++) {
            uint256 blockValue = uint256(blockhash(block.number - i));
            randomNumber = uint256(keccak256(abi.encodePacked(blockValue, randomNumber, i)));
        }
    }

    /**
     * @dev Creates `amount` tokens of token type `id`, and assigns them to `msg.sender`.
     */
    function mint(uint256 amount)
        public
    {
        for (uint i = 0; i < amount; i++) {
            // generateRandomNumber creates a new number everytime just before minting
            generateRandomNumber(i);
            // 4 is the max number and 1 is the minimum number
            // _mint(to, tokenId, amount, data)
            _mint(msg.sender, randomNumber % 4 + 1, 1, "");
        }
    }

    /**
     * @dev Hook that is called before any token transfer. This includes minting
     * and burning, as well as batched variants.
     */
    function _beforeTokenTransfer(address operator, address from, address to, uint256[] memory ids, uint256[] memory amounts, bytes memory data)
        internal
        whenNotPaused
        override(ERC1155, ERC1155Supply)
    {
        super._beforeTokenTransfer(operator, from, to, ids, amounts, data);
    }

    /**
     * @dev See {IERC1155MetadataURI-uri}.
     * Metadata displayed for NFT tokenID - Ex: 1.json
     */
    function uri(uint256 _tokenId) override public view returns (string memory) {
        if(!exists(_tokenId)) {
            revert("URI: nonexistent token");
        }
        return string(abi.encodePacked(super.uri(_tokenId), Strings.toString(_tokenId), ".json"));
    }

    /**
     * @dev Contract-level metadata
     */
    function contractURI() public view returns (string memory) {
        return string(abi.encodePacked(super.uri(0), "contract.json"));
    }
}
Deploying ERC1155 Card Collection To zkEVM Testnet
With out contract done, we’ll modify our deploy.ts file.
File: ./scripts/deploy.ts
// Imports
// ========================================================
import { ethers } from "hardhat";
import dotenv from "dotenv";

// Config
// ========================================================
dotenv.config();

// Imports
// ========================================================
async function main() {
  const Contract = await ethers.getContractFactory(`${process.env.CONTRACT_NAME}`);
  const contract = await Contract.deploy(`${process.env.BASE_URL}`);

  await contract.deployed();

  console.log(
    `${`${process.env.CONTRACT_NAME}`} deployed to ${contract.address}`
  );
}

// We recommend this pattern to be able to use async/await everywhere
// and properly handle errors.
main().catch((error) => {
  console.error(error);
  process.exitCode = 1;
});
We’ll update our .env file to reflect the CONTRACT_NAME, add our zkEVM RPC, and specify how many NFT types exist.
File: ./env
CONTRACT_NAME="ZkMythicCards"
NUMBER_NFT_TYPES="4"
RPC_ZKEVM_URL="https://rpc.public.zkevm-test.net"
WALLET_PRIVATE_KEY=""
BASE_URL=""
With the new environment variables, we’ll modify our hardhat.config.ts to support the RPC settings.
File: ./hardhat.config.ts
// Imports
// ========================================================
import { HardhatUserConfig } from "hardhat/config";
import "@nomicfoundation/hardhat-toolbox";
import dotenv from "dotenv";

// Config
// ========================================================
dotenv.config();

// Hardhat Config
// ========================================================
const config: HardhatUserConfig = {
  solidity: {
    version: "0.8.18",
    settings: {
      optimizer: {
        enabled: true,
        runs: 200,
      }
    }
  },
  networks: {
    zkevmTestnet: {
      url: `${process.env.RPC_ZKEVM_URL || ''}`,
      accounts: process.env.WALLET_PRIVATE_KEY
        ? [`0x${process.env.WALLET_PRIVATE_KEY}`]
        : [],
    }
  },
};

// Exports
// ========================================================
export default config;
With everything configured, let’s deploy our contract.
NOTE: Make sure you have zkEVM Testnet tokens. You can bridge Goerli to zkEVM through https://wallet.polygon.technology.
# FROM: ./zkevm-erc1155

npx hardhat run scripts/deploy.ts --network zkevmTestnet;

# Expected Output:
# Compiled 1 Solidity file successfully
# ZkMythicCards deployed to 0x914B74867e49cd2a9cfb5928d14618B98Aa4FB13
Polygonscan zkEVM Testnet Contract Deployed — https://testnet-zkevm.polygonscan.com/address/0x914B74867e49cd2a9cfb5928d14618B98Aa4FB13
zkEVM Testnet Contract Verification
NOTE: Unfortunately Polygonscan is having some issues with verification and for now we’ll be using https://explorer.public.zkevm-test.net instead.
Creating Standard-JSON-Input
In your compiled artifacts build-info folder, copy the entire input section and save it as a file called verify.json.
Copy Input JSON From build-info
Create new ./verify.json and paste the input details inside the JSON file
Verifying Contract On zkEVM Testnet Public Explorer
Go to your deployed contract at the following URL, select the Standard JSON Input method for verification, and upload the verify.json file.
# https://explorer.public.zkevm-test.net/address/0xDeployedContractAddress
zkEVM Testnet Public Explorer — Verify & Publish Contract
zkEVM Testnet Public Explorer — Select Standard Input JSON
zkEVM Testnet Public Explorer — Configure Verification
zkEVM Testnet Public Explorer — Successful Verification
Minting zkEVM ERC1155 NFTs
Making sure that our wallet is set to the zkEVM Testnet network, connect our wallet to the site, mint 5 NFTs, and then read one of the token IDs to see the result.
zkEVM Testnet Public Explorer — Ensure On zkEVM Testnet Network
zkEVM Testnet Public Explorer — Mint 5 NFTs & Confirm
zkEVM Testnet Public Explorer — Successful Minting
Once the mint was successful, go to the Read Contract section and input one of the four token IDs in the uri section.
zkEVM Testnet Public Explorer — Read Contract & Query Token ID
Arweave NFT Metadata
Arweave NFT Image From Metadata
Although OpenSea isn’t supporting zkEVM yet, if we deployed this contract to Polygon Mumbai, we can see that the NFT items can have multiple owners.
OpenSea Demonstrating ERC1155 With Multiple Owners
Full Code Git Repository
If you want to look at the full code repository on GitHub, check out https://github.com/codingwithmanny/zkevm-erc1155.
GitHub - codingwithmanny/zkevm-erc1155: How to deploy an ERC1155 Mythic Card Collection contract to zkEVM and arweave permaweb files
What’s Next?
Some next steps could be to add additional attributes to make this a fully functioning card game where people could create matches from deployed contracts.
If you want to learn how to deploy an Animated ERC721 Contract To zkEVM, make sure to check that article out.
If you got value from this, please give it some love, and please also follow me on twitter (where I’m quite active) @codingwithmanny and instagram at @codingwithmanny.