Forem: Gaurav Burande

Decoding a Solana on-chain account in JavaScript.

Gaurav Burande — Sun, 27 Apr 2025 06:21:11 +0000

The goal of this exercise is to understand how Accounts are stored on-chain on Solana and their structure.

No Anchor client
No special libraries
Just Buffer and raw byte parsing

Like Imagine you pulled account data from a Pubkey, and now you're reconstructing the Account struct from Solana manually with JavaScript.

For Example, an on-chain Rust account is:

#[account]
pub struct MyAccount {
    pub authority: Pubkey, // 32 bytes
    pub value: u64,        // 8 bytes
}

All the accounts on Solana are stored flat in memory, which takes exactly 48 bytes.

Bytes Range	Content	Size
0..8	Discriminator	8 bytes
8..40	Authority Pubkey	32 bytes
40..48	Value (u64)	8 bytes

The first 8 bytes are to identify which type of Account it is, or more like for safety, to make sure it is an "Account".

It's a unique identifier for your struct.
Prevents deserialising the wrong data into the wrong type.
Protects your program from bugs and hacks.

We use Borsh(Binary Object Representation Serializer for Hashing), which turns the Rust struct into bytes and when needed, bytes into the Account Struct, where:

Struct fields are stored in the order you declare them.
No gaps, no random alignment padding.
Everything is stored compactly.

Each field is serialised one after another in memory.

PubKey has 32 bytes, and the remaining data is 8 bytes in little-endian format.

If you ever change the order or the fields or add fields at the top, then you'll break old accounts on the mainnet because the byte layout will mismatch!
That's why in real projects, fields are always at the end!

Now you've got enough idea about the memory structure of accounts in Solana. Let's dive into decoding them in JS!

First, we have to fetch the account info.

import { Connection, PublicKey } from '@solana/web3.js';

const connection = new Connection('https://api.mainnet-beta.solana.com');

const accountPublicKey = new PublicKey('YourAccountAddressHere');

const accountInfo = await connection.getAccountInfo(accountPublicKey);

if (!accountInfo) {
  throw new Error('Account not found!');
}

const data = accountInfo.data; // This is a Buffer (or Uint8Array)

Now parse the data

We manually read the bytes:

// Skip the first 8 bytes (discriminator)
const authorityBytes = data.slice(8, 8 + 32); // bytes 8..40
const valueBytes = data.slice(40, 48);         // bytes 40..48

// Parse the pubkey
const authorityPubkey = new PublicKey(authorityBytes);

// Parse the u64 value
const value = Number(
  valueBytes.readBigUInt64LE(0) // read as little-endian
);

console.log('Authority:', authorityPubkey.toBase58());
console.log('Value:', value);

Visually step by step:

[0..8]    -> skip discriminator
[8..40]   -> authority pubkey (32 bytes) -> decode with PublicKey()
[40..48]  -> value (8 bytes) -> decode with readBigUInt64LE

The full code:

import { Connection, PublicKey } from '@solana/web3.js';

async function fetchAndDecodeMyAccount(addressStr) {
  const connection = new Connection('https://api.mainnet-beta.solana.com');
  const pubkey = new PublicKey(addressStr);

  const accountInfo = await connection.getAccountInfo(pubkey);

  if (!accountInfo) {
    throw new Error('Account not found');
  }

  const data = accountInfo.data;

  if (data.length !== 48) {
    throw new Error('Unexpected account size');
  }

  const authorityBytes = data.slice(8, 40);
  const valueBytes = data.slice(40, 48);

  const authority = new PublicKey(authorityBytes);
  const value = Number(valueBytes.readBigUInt64LE(0));

  return { authority: authority.toBase58(), value };
}

// Example usage
fetchAndDecodeMyAccount('YOUR_ACCOUNT_ADDRESS').then(console.log);

This way, you can read any Solana account manually in Javascript and you understand exactly how Solana memory layout works.

Why does slicing in Rust fail on anything that's not English?

Gaurav Burande — Wed, 16 Apr 2025 07:34:14 +0000

The thing is, slicing in Rust happens by byte index, not char index!

So when you do:

let full = String::from("hello world");
let part = &full[0..5]; // slice from index 0 to 5 (not inclusive)
println!("{}", part);   // prints "hello"

Every char here takes a 1 byte space when the string is in English.

'A'  => 01000001  (1 byte)
'z'  => 01111010  (1 byte)

So when you slice from the 0th to the 4th index on the bytes, you get "hello"!

Unlike this, let's say when you do something like using Unicode characters, Hindi characters or emojis. Let's take an example:

let s = String::from("नमस्ते");
let slice = &s[0..3]; // ⚠️ this will panic!

Why do you think this panicked?
Rust strings are UTF-8 encoded, meaning that other than English, characters or emojis may take more than 1 byte of space.

Character	UTF-8 Encoding	Bytes
A	0x41	1
ñ	0xC3 0xB1	2
न	0xE0 0xA4 0xA8	3
😊	0xF0 0x9F 0x98 0x8A	4

So yeah, Hindi characters like न use 3 bytes!

So when you slice "नमस्ते" from 0th to 2nd index, you're basically slicing in the middle of a character, which is invalid UTF-8.
So:

&s[0..3] → valid (न)
&s[0..2] → ❌ invalid, slicing inside the byte-sequence of न

Rust is very strict about UTF-8 string encoding, so the rumtime panics!

Then how do you slice properly?
Rust gives you two options:

1. Slice using char indices:

let s = String::from("नमस्ते");
let first_char = s.chars().nth(0).unwrap(); // ✅ gives 'न'

2. Use .get() with range:

let slice = s.get(0..3); // returns Option<&str>

So you can safely do:

if let Some(valid_slice) = s.get(0..3) {
    println!("{}", valid_slice);
}

This way, Rust won’t panic if the range is invalid, and it just gives you None as a Result variant.

✅ Always slice only if you know you’re at valid UTF-8 character boundaries.

How to implement custom domains for pages in NextJS.

Gaurav Burande — Mon, 29 Jan 2024 07:50:12 +0000

I'm a full-stack developer.

when I was looking at some support tickets I saw that most users were asking for a custom domain for their landing pages.

I started researching on Google and asked chatgpt, but the resources were not specific to my problem statement, they were just okay.

My first open-source contribution was to the EddieHub organization.

I casually revisited one of their projects - BioDrip, they had custom domains for user profiles, where normally the user profiles were just a landing page.

I was so lucky.
The tech stack for makelanding.ai and BioDrip were the same - NextJS.

I started reading the pull request for the custom domain feature.

Technically, having a custom domain for pages is impossible - a discord user replying to my help post.

The custom domains actually point at the IPv4 address of makelanding.ai - 76.76.21.21.

If the users wanted a subdomain for their landing page then they had to add a CNAME record with value cname.vercel-dns.com.

NextJs middleware which runs on the edge runtime can be used for many purposes:

A/B testing landing pages
Authentication
Geo-specific content delivery
Authentication
Personalization, which is the same as Geo-specific content delivery
Rewriting the response, which I used to serve the pages on custom domains.

When a user adds a custom domain to their landing page, It's added to the domains of the Vercel project, and I'm just verifying if the domain has configured the DNS records correctly using this vercel API: https://api.vercel.com/v10/domains/${domain}/config?teamId=${process.env.VERCEL_TEAM_ID}

To create the middleware in a NextJs project you just have to create a middleware.js or middleware.ts file in the root folder.

By default, the middleware will run on all the routes, API, and pages, but you can specify the routes, where you want to run the middleware by a config variable export:

export const config = {
    matcher: [
        "/",

        // page management
        "/page/:path*",
        "/api/page/domain",
    ],
};

You don't want to run middleware on API routes where you're using dependencies, because middleware runs on edge runtime and to be fast it is like a minified version of nodejs, its edge runtime only supports few web APIs and the max size for a route's executed code running on edge is between 1MB - 4MB.

It'd be better to just visit the NextJs middleware doc rather than understand my explanation.

How this works is when the custom domain has configured the DNS records correctly and it's pointing to the vercel deployed project, the middleware checks the host which is making the request to the project's IPv4 address.

const hostname = req.headers.get("host");
    const reqPathName = req.nextUrl.pathname;
    const hostedDomain = process.env.NEXT_PUBLIC_BASE_URL.replace(
        /http:\/\/|https:\/\//,
        "",
    );
    const hostedDomains = [hostedDomain, `www.${hostedDomain}`, `preview.${hostedDomain}`];

    const regex = /^(.*\.)?vercel\.app$/;

    const vercelSubdomain = regex.test(hostname);

    // if custom domain + on root path
    if (!hostedDomains.includes(hostname) && !vercelSubdomain && reqPathName === "/") { 
    console.log("custom domain for landing page")
}

If the host is not the hostedDomain for the vercel project or the subdomain provided by vercel for the projects, then we proceed.

Then check if the custom domain exists in the database, get the corresponding landing page to that specific custom domain, and rewrite the response! Easy!

if (
            page?.domain &&
            page?.domain === hostname
        ) {
            console.log(
                `custom domain "${hostname}", matched for page "${page.name}" (protocol: "${protocol}")`,
            );
            //If a match is found, rewrite to the custom domain and display the page
            return NextResponse.rewrite(
                new URL(
                    `/page/${page.id}`,
                    `${protocol}://${page.domain}`,
                ),
            );
        } else {
            console.error("something went wrong with serving the page on custom domain: " + page.domain)
        }