An in-depth analysis of a $1M open-source personal finance application built with Ruby on Rails

Maybe finance

Maybe finance breakdown


## Introduction: a standard for high-fidelity mentorship

The goal of shadowing is to transfer skills effectively, not to fight with tools or slow procedures, or create a security situation like sharing GitHub credentials. To make this work, we're experimenting a protocol that prioritizes direct and efficient collaboration.

We use a focused set of tools to create a fast feedback loop: **tailscale** provides a simple and secure peer-to-peer network, while **git** and the **aerc** email client enable a mail-driven workflow. This approach keeps the entire review process inside the terminal, close to where the actual engineering happens. This is a similar workflow you would see when **contributing to the Linux Kernel**.

### Workflow overview

```mermaid
graph TD
    A["Shadow: Develop Code on Feature Branch"] --> B{"Shadow: Commits Ready?"};
    B -- Yes --> C["Shadow: Generate Patches 'git format-patch main'"];
    C --> D["Shadow: Send Patches via Email 'git send-email' or 'aerc'"];
    D --> E["Mentor: Receive Patch Emails"];
    E --> F{"Mentor: Review Patches"};
    F -- Approved --> G["Mentor: Apply Patches 'git am 00*.patch'"];
    G --> H["Mentor-Side Hook: 'post-applypatch' (Updates Commit Author)"];
    H --> I["Code Integrated"];
    B -- No --> A;
    F -- Changes Needed --> D;
```

## 1. The network fabric: establishing read-only git access with tailscale

The foundational layer of this protocol is a secure, zero-configuration peer-to-peer network. We use **tailscale** to create a private **tailnet**, placing the mentor's and the shadow's machines on the same virtual local area network. This allows the shadow to have read-only access to the mentor's git repository via the **git daemon**, eliminating complex firewall or public IP configurations.

The mentor first shares their machine with the shadow via **tailscale node sharing**. Once connected, the mentor starts the git daemon in the repository directory they wish to share.

```bash
# mentor: from within the project directory to be shared
git daemon --verbose --export-all --base-path=. --reuseaddr
```

The shadow can then verify connectivity by pinging the mentor's **tailscale magicdns name** or ip address.

```bash
# shadow: verify connection to mentor's machine
ping <mentor-tailscale-magicdns-name-or-ip>
```

With the connection verified and the **git daemon** running on the mentor's machine, the shadow can clone the repository using the mentor's **tailscale magicdns name** (e.g., `mentor-machine-name`) and the repository's directory name (which is `.` in the `base-path`, so it refers to the directory name itself).

```bash
# shadow: clone the repository
# replace <mentor-tailscale-magicdns-name> with the mentor's actual tailscale machine name
# replace <repository-folder-name> with the name of the directory the mentor is sharing
git clone git://<mentor-tailscale-magicdns-name>/<repository-folder-name>
```

This setup provides a simple, secure, and read-only channel for the shadow to access the codebase. The **node sharing** feature ensures the shadow only has network access to the mentor's designated machine.

## 2. The transport mechanism: asynchronous review with git and aerc

This protocol utilizes the time-tested, email-based workflow originally developed for large-scale distributed projects like the Linux kernel. This method decouples the code submission and review process from a centralized platform, enabling true asynchronicity.

The shadow serializes their git commits into a **patch series** using the **git format-patch** command. These patches are self-contained text files that represent a discrete unit of work. The patches are then transmitted via email, where they can be reviewed and applied by the mentor.

While `git send-email` is the standard tool for dispatching patches, using a terminal-based email client like **aerc** is highly recommended for  the mentor. For the mentor, **aerc** offers powerful features for viewing patches directly in the terminal and can simplify the process of piping email content directly to `git am`, further reducing context switching. However, the use of **aerc** is optional, and the core protocol functions effectively with any email client capable of handling plain text attachments or inline patches.

The primary commands for this stage are as follows:

```bash
# shadow: from within your feature branch, create patches for commits
# that are not yet in the 'main' branch.
git format-patch main

# this will create one or more .patch files in your current directory,
# for example: 0001-add-new-feature.patch
```

Once the patches are created, they are sent to the mentor for review.

```bash
# shadow: use git's built-in email tool to send the patch series.
# ensure your .gitconfig is set up for sending email.
git send-email --to="mentor.email@example.com" 00*.patch
```

Otherwise, you can also specify the relative commit without creating a patch:

```bash
git send-email HEAD~3 --to="mentor.email@example.com"
```

This command dispatches each patch as a properly formatted email, ready for inspection and application.

## 3. The end-to-end operational workflow

The complete process provides a clear and efficient loop for submitting, reviewing, and integrating code.

1.  **Network setup.** The mentor shares a **tailscale node** with the shadow. The shadow accepts. The mentor starts `git daemon` in the project directory. The shadow verifies the connection and clones the repository. This step is typically only performed once at the beginning of the shadowing period, with the `git daemon` being run by the mentor as needed.
2.  **Task execution.** The shadow completes a task on a local feature branch, making one or more well-formed, atomic commits.
3.  **Patch generation.** The shadow generates the patch files from their commits.

    ```bash
    # shadow: create patches from your current branch against the main branch.
    git format-patch main
    # output:
    # 0001-refactor-the-authentication-module.patch
    # 0002-add-unit-tests-for-new-auth-flow.patch
    ```
4.  **Patch submission.** The shadow sends the generated files using **git send-email** or an integrated client like **aerc**.

    ```bash
    # shadow: send all generated .patch files.
    git send-email --to="mentor.email@example.com" 00*.patch
    ```
5.  **Review and application.** The mentor receives the patches as emails. They can review the code directly in their client. If the changes are approved, they use **git am** (apply mail) to apply the patches directly to their local repository. This command applies the commits exactly as the shadow created them, preserving authorship and commit history with perfect fidelity. If using **aerc**, the mentor can often pipe the email directly to `git am` for even faster application.

    ```bash
    # mentor: apply all patches from the received emails (saved as .mbox or .eml files).
    # assuming the patches were saved to files, or piped from an email client like aerc.
    # Example with saved files:
    git am 00*.patch
    # Example with aerc (conceptual, actual command might vary based on aerc setup):
    # <select email in aerc> | -m git am
    ```

## 4. Standardizing authorship upon application (mentor-side hook)

To ensure that the final commit author reflects the individual applying the patch (the mentor or representative), a **git hook** is utilized on the mentor's machine. The **post-applypatch** hook runs *after* `git am` creates a commit, allowing the commit to be amended.

This hook will automatically amend the last commit to update the author field to the mentor's configured git user name and email. The original author's information from the patch is initially used by `git am` to create the commit, and then this hook immediately changes it.

**Setup (mentor's machine):**

**Option 1: Per-repository setup**
1.  Navigate to the git repository where patches will be applied.
2.  Create or edit the file `.git/hooks/post-applypatch`.
3.  Make the file executable: `chmod +x .git/hooks/post-applypatch`.
4.  Add the following script content to the `post-applypatch` file:

**Option 2: Global setup (for new repositories or configured existing ones)**
Alternatively, to apply this hook globally for new repositories or to set it as a global hook path:
1.  Create the hooks directory if it doesn't exist: `mkdir -p ~/.git-templates/hooks`.
2.  Create the `post-applypatch` file in this directory: `~/.git-templates/hooks/post-applypatch`.
3.  Make the file executable: `chmod +x ~/.git-templates/hooks/post-applypatch`.
4.  Add the script content (shown below) to `~/.git-templates/hooks/post-applypatch`.
5.  For **new** repositories, Git will automatically copy hooks from `~/.git-templates/hooks/` when you run `git init` or `git clone`.
6.  For **existing** repositories, you can either re-initialize them (`git init`) to copy the hooks from the template, or configure Git to use this global path directly (Git 2.14+):
    ```bash
    git config --global core.hooksPath '~/.git-templates/hooks'
    ```
    Note: `core.hooksPath` will make Git look for hooks *only* in the specified directory, bypassing the per-repository `.git/hooks/` directory unless the global directory doesn't contain a specific hook. If you use `core.hooksPath`, ensure all your global hooks are in that one location.

**Script Content for `post-applypatch`:**

    ```bash
    #!/bin/sh
    #
    # post-applypatch hook
    #
    # This hook runs after 'git am' creates a commit.
    # We amend that commit to replace the author with the
    # currently configured git user.name and user.email.

    echo "--- Post-applypatch hook: Correcting commit author ---"

    # Get the mentor's configured git user name and email
    MENTOR_NAME=$(git config user.name)
    MENTOR_EMAIL=$(git config user.email)

    if [ -z "$MENTOR_NAME" ] || [ -z "$MENTOR_EMAIL" ]; then
      echo "Error: Git user.name and user.email are not configured for the mentor." >&2
      echo "Author not changed. Please configure them to use this post-applypatch hook." >&2
      exit 0 # Exit 0 so as not to block 'git am' if user isn't configured
    fi

    git commit --amend --no-edit --author="$MENTOR_NAME <$MENTOR_EMAIL>"

    echo "--- Author successfully changed to $MENTOR_NAME <$MENTOR_EMAIL> ---"

    exit 0
    ```

**How it works:**
When the mentor runs `git am 00*.patch`, after each patch is successfully applied and committed (using the original author from the patch), this `post-applypatch` hook will execute. It then immediately runs `git commit --amend` to change the author of the just-created commit to the mentor's configured `user.name` and `user.email`, without altering the commit message or the commit's content.

This ensures that the commit history in the repository accurately reflects who performed the final integration. The shadow's contribution is still evident from the patch content and the original commit message (which is preserved by `--no-edit`). For even clearer attribution, the mentor could still manually add a "Co-authored-by: Shadow Name <shadow.email@example.com>" line to the commit message if desired, or the hook could be extended to do this.

This protocol will hopefully ensure a robust and efficient standard for shadowing, minimizing logistical overhead and allowing both mentor and shadow to focus on the code


A standard operating procedure for a high-fidelity, low-latency shadowing workflow using git, tailscale, and aerc.

A protocol for asynchronous shadowing


![](assets/build_custom_ai_agent_with_elizaos_intro.webp)

DeFAI stands for Decentralized Finance Artificial Intelligence, which combines the principles of decentralized finance (DeFi) with artificial intelligence (AI) to enhance financial services by leveraging AI's predictive analytics and automation features.
With ElizaOS, you can build and deploy a DeFAI Agent—an AI persona that interacts with users on online platforms, assists with transactions, analyzes market trends, and executes financial tasks in a decentralized and automated manner.

## What is a ElizaOS?

A comprehensive framework for building AI agents with persistent personalities across multiple platforms. ElizaOS provides the architecture, tools, and systems needed to create sophisticated agents that maintain consistent behavior, learn from interactions, and seamlessly integrate with a variety of services.

## How ElizaOS works?

![](assets/build_custom_ai_agent_with_elizaos_system.webp)

When a user message is received, here's what happens behind the scenes:

1. **Service reception**: Platform service (Discord, Telegram, etc.) receives the message
2. **Runtime processing**: Agent runtime coordinates the response generation
3. **Context building**: Providers supply relevant context (time, recent messages, knowledge)
4. **Action selection**: The agent evaluates and selects appropriate actions
5. **Response generation**: The chosen action generates a response
6. **Learning & reflection**: Evaluators analyze the conversation for insights and learning
7. **Memory storage**: New information is stored in the database
8. **Response delivery**: The response is sent back through the service

## Build custom AI agent with ElizaOS

![](assets/build_custom_ai_agent_with_elizaos_flow.webp)
To build AI Agent with ElizaOS, we focus on four concepts:

- **Characters**: JSON config files defining AI personality and behavior
- **Agents**: Runtime components managing memory and executing behaviors
- **Providers**: Data connectors injecting context into interactions
- **Actions**: Executable behaviors that agents can perform

### Characters

Characters are the personality profiles that define how an agent behaves and responds. Think of them as the "script" your AI follows to maintain consistent behavior.

For example, we created a battle-hardened DeFi veteran called "YieldMaxoor" who had survived multiple market crashes and could spot scams from a mile away. Here's a simplified version of the character configuration:

```json
{
  "name": "YieldMaxoor",
  "clients": [],
  "modelProvider": "openai",
  "settings": {
    "chains": {
      "evm": ["baseSepolia"]
    }
  },
  "plugins": [],
  "bio": [
    "YieldMaxoor is a battle-tested DeFi degen who's been farming since the 2020 'DeFi Summer'",
    "Speaks in crypto-native slang and always DYOR-pilled",
    "Claims every new protocol is 'probably not a rug' and 'ser, the APY is real'",
    "Frequently mentions their portfolio being 'down bad' but 'still bullish'"
  ],
  "lore": [
    "Started yield farming during DeFi Summer 2020",
    "Survived multiple bear markets and 'temporary' depeg events",
    "Specialist in hunting the highest APYs across chains",
    "Always emphasizes DYOR while aping first, reading docs later"
  ],
  "knowledge": [
    "Yield farming strategies",
    "DEX liquidity provision",
    "Cross-chain bridges",
    "MEV protection",
    "Smart contract risk assessment",
    "Gas optimization",
    "Impermanent loss calculations",
    "Tokenomics analysis"
  ],
  "messageExamples": [
    [
      {
        "user": "{{user1}}",
        "content": {
          "text": "What do you think about this new farm?"
        }
      },
      {
        "user": "YieldMaxoor",
        "content": {
          "text": "ser, the APY is looking juicy af. audit's coming 'soon™' but team is based. probably not a rug. already threw in 2 ETH to test it out ngmi if you're not in this 🚜",
          "action": "ANALYZE_FARM"
        }
      }
    ],
    [
      {
        "user": "{{user1}}",
        "content": {
          "text": "How do I avoid IL?"
        }
      },
      {
        "user": "YieldMaxoor",
        "content": {
          "text": "fren, IL is just a temporary state of mind. but if you're ngmi with that, stick to stables farming or single-sided staking. this is financial advice because i'm already poor 😅",
          "action": "EXPLAIN_IL"
        }
      }
    ],
    [
      {
        "user": "{{user1}}",
        "content": {
          "text": "Is this protocol safe?"
        }
      },
      {
        "user": "YieldMaxoor",
        "content": {
          "text": "anon, i've been rugged so many times i can smell them coming. this one's based - doxxed team, good tvl, clean code. but always DYOR and don't put in more than you can lose ser 🤝"
        }
      }
    ]
  ],
  "postExamples": [
    "gm frens, just found a 4 digit APY farm. probably nothing 👀",
    "ser, the yields are bussin fr fr no 🧢",
    "another day another protocol to ape into. wagmi 🚜"
  ]
}
```

The character definition includes not just knowledge areas, but also speaking style and sample interactions that help the AI maintain consistency.

### Agents

Agents are the runtime components that bring your characters to life. They manage the actual execution of your AI's behaviors through the AgentRuntime class.

The main configuration requires a database adapter for persistence (e.g., mongodb, postgres, sqlite, etc.) , a model provider (e.g., openai, anthropic, etc.) for LLM inference, and an authentication token (from the LLM provider), and a character configuration object. Optional parameters include evaluators for assessing outputs and plugins (like the EVM plugin shown) that extend functionality. Here's an example:

```typescript
return new AgentRuntime({
  databaseAdapter: db,
  token,
  modelProvider: character.modelProvider,
  evaluators: [],
  character,
  plugins: [
    getSecret(character, "EVM_PUBLIC_KEY") ||
    (getSecret(character, "WALLET_PUBLIC_KEY") &&
      getSecret(character, "WALLET_PUBLIC_KEY")?.startsWith("0x"))
      ? evmPlugin
      : null,
  ],
});
```

### Actions

Actions are components that define how the agent responds to messages and interacts with them. They enable the agent to interact with external systems, modify behaviors, and perform tasks beyond simple message responses.

```typescript
const customAction: Action = {
  name: "CUSTOM_ACTION",
  similes: ["SIMILAR_ACTION"],
  description: "Action purpose",
  validate: async (runtime: IAgentRuntime, message: Memory) => {
    // Validation logic
    return true;
  },
  handler: async (runtime: IAgentRuntime, message: Memory) => {
    // Execute custom logic
  },
  examples: [],
};
```

### Provider

A module that injects dynamic context and real-time information into agent interactions. In example, provider is responsible for passing real-time information to the agent.

```typescript
const timeProvider: Provider = {
  get: async (_runtime: IAgentRuntime, _message: Memory, _state?: State) => {
    const currentDate = new Date();

    // Since the bot will communicate with users worldwide, it fetches UTC time.
    const options = {
      timeZone: "UTC",
      dateStyle: "full" as const,
      timeStyle: "long" as const,
    };
    const humanReadable = new Intl.DateTimeFormat("en-US", options).format(
      currentDate,
    );
    return `The current date and time is ${humanReadable}. Please use this as your reference for any time-based operations or responses.`;
  },
};
```

## What we achieved?

We have developed an ICY Swap AI Agent that allows users to check their ICY balance and seamlessly exchange ICY for BTC by implementing a `degen` character and the `plugin-icy-swap` plugin, fully integrated with the ElizaOS ecosystem.

[Source code](https://github.com/quanghuynguyen1902/eliza-icy-swap)

## Reference

- https://github.com/elizaOS/eliza-plugin-starter
- https://www.quicknode.com/guides/ai/how-to-setup-an-ai-agent-with-eliza-ai16z-framework


This guide shows how to build a custom AI Agent with ElizaOS.

Build custom AI agent with ElizaOS


![](assets/dynamic-liquidity-market-a-new-form-of-concentrated-liquidity-amm-on-solana-1.webp)

## Introduction

Dynamic Liquidity Market Maker (DLMM) is a new form of concentrated liquidity AMM on Solana, developed to make it easier and more sustainable for users and project teams to provide broader, deeper liquidity on Solana. DLMM aim to improve LP profitability with dynamic fees, allow new tokens to bootstrap their liquidity in new creative ways, and allow LPs a broader array of LP strategies and more precise liquidity concentration.

![](assets/dynamic-liquidity-market-a-new-form-of-concentrated-liquidity-amm-on-solana-2.webp)

## Technical overview of DLMM

The DLMM allows liquidity providers to contribute to discrete liquidity bins, enabling them to specify buy or sell orders for token pairs at predetermined prices. Essentially, the DLMM's liquidity pools consist of numerous price-specific bins filled with tokens by LPs. Trading within these pools transitions sequentially from one bin to another as tokens are exchanged, ensuring continuous market operation.

### DLMM bin price

Liquidity is distributed across discrete bins with a fixed width and fixed price. Within each bin, liquidity can be exchanged at a fixed price **X + Y = k** within each bin. Basically you add **X** tokens and take out **Y** tokens (or vice versa), until there is only just one type of token left.

Each bin represents a single price point, and difference between 2 consecutive bins is the bin step. Bin steps are calculated based on the basis points set by the pool creator. For example, taking SOL/USDC. If the current price is $20 and the bin step is 25 basis points (0.25%), then the consecutive bins would be 20 x 1.0025 = 20.05, 20.05 \* 1.0025 = 20.10 and so on.

### Bin liquidity

Liquidity in each bin is calculated by the constant sum price variant, `𝑃.𝑥+𝑦=𝐿`, where **_x_** is the quantity of token **X**, **_y_** is the quantity of token **Y**, **L** is the amount of liquidity in the bin and `𝑃=Δ𝑦/Δ𝑥`. **P** is defined as the rate of change of **Y** reserves per change in **X** reserves, and is a price constant unique to each pool.

**P** can be visualized as the gradient of the line in the following image:

![](assets/dynamic-liquidity-market-a-new-form-of-concentrated-liquidity-amm-on-solana-3.webp)

### Market aggregation

The constant sum curve intercepts both the **x** and **y** axes, meaning that the reserves of **X** or **Y** token can be exhausted. When this happens, the current price would move to the next bin either on the left or right.

Active price bin is defined as the bin that contains reserves of both **X** and **Y**. Note that there can only be one active bin at any point in time. All bins to the left of the active bin will only contain token **Y**, while all bins to the right of it will only contain token **X**.

![](assets/dynamic-liquidity-market-a-new-form-of-concentrated-liquidity-amm-on-solana-4.webp)

## Differences over other models

### Over AMMs

DLMMs offer a number of benefits over traditional automated market makers (AMMs):

- Reduced slippage: By concentrating liquidity in a specific price range, DLMMs reduce the amount of slippage that traders experience.
- Improved capital efficiency: DLMMs allow liquidity providers to deposit their assets into specific price bins, which makes better use of their capital.
- Deeper liquidity: DLMMs can provide deeper liquidity for asset pairs, even those with low trading volume.
- Improved LP profitability: Dynamic fees allow LPs to make more money on market volatility

### Over CLMMs

![](assets/dynamic-liquidity-market-a-new-form-of-concentrated-liquidity-amm-on-solana-5.webp)

## Advantages of DLMM

DLMM offers several benefits but the main ones include:

**Zero Slippage**: Trading within an active bin has zero slippage or price impact. This makes it easier for LPs to concentrate their liquidity even further and capture more volume and fees than they could before.

**Higher capital efficiency:** DLMM offers zero slippage for swaps within the same bins. Further, it also supports lower liquidity requirements and higher volume of trading as liquidity is concentrated on the market value.

**Better profitability and flexibility:** LPs can create richer and more precise strategies by creating liquidity shapes that suit their need. Profitability is also increased as LPs earn a base fee as well as a variable fee when price actions become more volatile, causing the DLMM to switch bins.

## What’s next?

Today, Jupiter is leveraging the DLMM model in its Launchpad, there are many project using Jup Launchpad such as:

- [Jupiter](https://jup.ag/) - Top DEX aggregator in crypto.
- [Zeus Network](https://zeusnetwork.xyz/) - Permissionless communication layer connecting. Solana and Bitcoin.
- [Uprock](https://uprock.com/) - The premier DePIN network fueling AI

In addition, users can create a new pool or add liquidity to the existing DLMM pool to earn fees by visit [Meteora DLMM pools](https://app.meteora.ag/dlmm).

## References

https://docs.meteora.ag


a new form of concentrated liquidity AMM on solana

Dynamic liquidity market maker - a new form of concentrated liquidity AMM on Solana


![](assets/introduce-to-solana-token-2022-new-standard-to-create-a-token-in-solana-1.webp)

## Introduction

Solana Token 2022 Program (Token extensions) is the next generation of the Solana Program Library standard. Token extensions introduce a new set of ways to extend the normal token functionality. The original Token program brought the basic capabilities of minting, transferring and freezing tokens. The Token Extensions program includes the same features, but come with additional features such as confidential transfers, custom transfer logic, extended metadata, and much more.

## Key features

![](assets/introduce-to-solana-token-2022-new-standard-to-create-a-token-in-solana-2.webp)

**Transfer Fees**: add a fee/tax on transfers of your token. specifically, you collect the fee in the token itself not another token like SOL (i.e. if TokenX has a transfer fee, then every time someone transfers or swaps TokenX, they would pay the fee in TokenX).

**Non-Transferable**: help you to create tokens that cannot be transferred. This enables the creation of "soul-bound" tokens, where digital assets are intrinsically linked to an individual. While these tokens cannot be transferred, the owner can still burn tokens and close the Token Account.

**Permanent Delegate**: specifies a permanent account delegate for any token account associated with the mint.

**Transfer Hook**: allows custom logic to be executed during token transfers, enabling advanced functionalities.

**Metadata**: allows you to have custom metadata directly on the token mint (similar idea to using the Token Metadata program from metaplex, except you will have 1 less account and need to pay less storage rent because of that)

**Confidential Transfer**: allow to mask token balances and the amounts of token transfers, with auditability from the issuer of the token

**Default Account State**: provides the option to have all new Token Accounts to be frozen by default.

## Benefits of using token extensions

Compared to Solana token standard, token extensions offer many benefits for both developers and businesses, making them a powerful tool for unlocking the full potential of the Solana blockchain. Here are some key benefits of Solana token extensions:

**Enhanced Functionality**: Token extenstions allow developers to equip tokens with new features and functionalities. This can range from things like privacy-protecting confidential transfers to setting up automatic fees or even adding interest-bearing capabilities.

**Security**: For developers, token extensions are a boon as they provide a standardized and pre-built set of tools. This eliminates the need to craft complex smart contracts from scratch, saving time and resources. With extensions, developers can focus on their core business logic instead of getting bogged down in the intricacies of smart contract development.

**Regulatory Compliance**: Solana Token Extensions can be instrumental in ensuring tokens comply with regulations. Features like adding required metadata or creating non-transferable tokens can be easily implemented using extensions. This makes Solana a more attractive platform for businesses and organizations that need to adhere to strict compliance standards.

## Use cases

### [Bern](https://www.bernboard.com/)

**Token extensions used**: Transfer Fees.

As the first token built with Token-22, BERN offers a fun way to engage with Solana’s famous community coin, BONK. Whenever a holder transfers BERN, the **Transfer Fee** extension ensures that 6.9% of the transferred amount is automatically taken as a fee.

Of this fee, 1% is used to burn BONK, 0.5% is used to burn BERN, and 5% is distributed back to holders of BERN. To date, nearly $1.5 million of BONK has been burned, and over $500,000 of BERN has been distributed to holders.

![](assets/introduce-to-solana-token-2022-new-standard-to-create-a-token-in-solana-3.webp)

### [Wen New Standard (WNS)](https://www.jupresear.ch/t/wen-new-standard-wns-0-0/133)

**Token extensions used**: Metadata & Metadata Pointer, Transfer Hook, Immutable Owner, Group & Group Pointer, Member & Member Pointer.

WNS is an extremely lightweight NFT standard built on top of Token2022 for maximum ecosystem composability, flexibility and backward compatibility. WNS 0.0 starts off extremely simple, with a single instruction for creating a new NFT by locking supply at 1 and giving it 0 decimals. The metadata is embedded in the Mint account and has only 3 fields (name, symbol, uri).

With the **Immutable Owner** and **Transfer Hook** extensions, WNS allows creators to configure royalties on their collections. Through the power of token extensions, these royalties are enforced at the protocol level, ensuring that they can’t be bypassed.

WNS also makes developers lives easier by simplifying how metadata is associated with each token. WNS uses **Metadata** and **Metadata Pointer** extensions to stores core info like each token’s Name, Symbol, and URI directly in the token mint itself.

### [Paxos USDP Stablecoin](https://paxos.com/usdp/)

**Token extensions used**: Mint Close Authority, Permanent Delegate, Confidential Transfer, Transfer Hook, Metadata & Metadata Pointer.

Paxos is regulated by the New York Department of Financial Services (NYDFS) as a trust company and is a fully-backed, US-dollar stablecoin issuer. For the launch of its Pax Dollar (USDP) stablecoin, Paxos chose to enable token extensions.

USDP also enabled the **Confidential Transfer** extension, a privacy-enabling feature that encrypts token balances and transfer amounts via zero-knowledge proofs. That allows merchants to provide confidentiality for transaction amounts to their consumers while maintaining visibility for regulatory purposes.

The NYDFS requires that Paxos prevents bad actors from accessing USDP. To do this, Paxos specifically enabled the **Permanent Delegate** extension. If funds are used for illegal purposes, this powerful extension allows Paxos to clawback funds, therefore meeting the strict regulatory requirements set by the NYDFS.

## What's next ?

Today, there are over a dozen token extensions at the program level unlocking new use-cases, such as:

- Building a better stablecoin.
- Leveling up game assets.
- Governance for real-world asset (RWA) issuance.

Token extensions are already seeing adoption across the ecosystem.

- [GMOTrust](https://x.com/GMOTrust) announced it will release GYEN & GUSD on Solana.
- [Paxos](https://x.com/Paxos) expanded stablecoin issuance to Solana.
- [phantom](https://x.com/phantom), [solflare_wallet](https://x.com/solflare_wallet), [FluxbeamDEX](https://x.com/FluxBeamDEX) & more support token extensions

## References

https://solana.com/developers/guides/token-extensions/getting-started


Explore Solana Token 2022, the next-generation token standard on Solana blockchain. Learn about its key features like transfer fees, non-transferable tokens, and confidential transfers. Discover how Token Extensions enhance functionality, improve security, and enable regulatory compliance for developers and businesses in the Solana ecosystem.

Introduce to Solana token 2022 - new standard to create a token in Solana


## Introduction

Solana is a high-performance blockchain platform designed for decentralized applications and cryptocurrencies. Known for its fast transaction speeds and low costs, Solana uses a unique consensus mechanism called Proof of History (PoH) to achieve high throughput and scalability. It supports a growing ecosystem of decentralized finance (DeFi) projects, non-fungible tokens (NFTs), and other applications.

To help everyone understand Solana to write smart contracts on it, this article will introduce the core concepts of Solana.

## Accounts

Accounts are where data is stored on the Solana blockchain*.* Accounts can store up to 10MB of data, which consit of either excutable program code or program state. Accounts require a rent deposit in SOL, proportional to the amount of data stored, which is fully refundable when the account is closed. Every account has a program "owner". Only the program that owns an account can modify it data.

![](assets/solana-core-concepts-1.webp)

## Types of accounts

There are two types of accounts on the Solana blockchain: executable and non-executable. Programs are executable accounts and store the immutable code of a program. Data storage and token balances are stored in non-executable accounts as their data can be changed. To control who can change this data, non-executable accounts have an owner program address assigned to them.

For each type of account, there will be typical accounts.

![](assets/solana-core-concepts-2.webp)

Data accounts store data

Program accounts store executable programs

Native accounts that indicate native programs on Solana such as System, Stake, and Vote

Within data accounts, there are 2 types:

- System owned accounts
- PDA (Program Derived Address) accounts

## Programs

Solana Programs, often called "smart contracts" on other blockchains, are the executable code that interprets the instructions sent inside of each transaction on the blockchain. They can be deployed directly into the network’s core as Native Programs or published by anyone as On Chain Programs. Programs are the core building blocks of the network and handle everything from sending tokens between wallets to accepting votes of DAOs, to tracking ownership of NFTs.

Unlike most other blockchains, Solana completely separates code from data. All data that programs interact with are stored in separate accounts and passed in as references via instructions. This model allows for a single generic program to operate across various accounts without requiring additional deployments.

## Types of programs

The Solana blockchain has two types of programs:

- Native programs
- On chain programs

Native programs are those built directly into the core of the Solana blockchain. These programs are divided into [Native Programs](https://docs.solana.com/developing/runtime-facilities/programs#bpf-loader) and [Solana Program Library (SPL) Programs](https://spl.solana.com/).

On chain programs is user-written programs, often called "smart contracts" on other blockchains, are deployed directly to the blockchain for anyone to interact with and execute.

## Transactions and instructions

On Solana, we send transactions to interactions with the network. Transactions include one or more instructions, each representing a specific operation to be processed. The execution logic for instructions is stored on programs deployed to the Solana network, where each program stores its own set of instructions.

![](assets/solana-core-concepts-3.webp)

An instruction is a request to process a specific action on-chain and is the smallest contiguous unit of execution logic in a program. You can imagine a instruction as a function which handles logic on web2.

Each instruction must include the following information:

- Program address: Specifies the program being invoked.
- Accounts: Lists every account the instruction reads from or writes to, including other programs.
- Instruction Data: A byte array that specifies which instruction handler on the program to invoke, plus any additional data required by the instruction handler (function arguments).

![](assets/solana-core-concepts-4.webp)

## Program Derived Addresses (PDAs)

PDAs are addresses that are deterministically derived and look like standard public keys, but have no associated private keys. This means that no external user can generate a valid signature for the address. However, the Solana runtime enables programs to programmatically "sign" for PDAs without needing a private key.

![](assets/solana-core-concepts-5.webp)

PDA was created can sign transactions to modify its data. That is very useful when you need storage that can only be modifiable by your program.

## Cross Program Invocations (CPIs)

A Cross Program Invocation (CPI) refers to when one program invokes the instructions of another program. This mechanism allows for the composability of Solana programs.

You can think of instructions as API endpoints that a program exposes to the network and a CPI as one API internally invoking another API.

![](assets/solana-core-concepts-6.webp)

When a program initiates a Cross Program Invocation (CPI) to another program:

- The signer privileges from the initial transaction invoking the caller program (A) extend to the callee (B) program.
- The callee (B) program can make further CPIs to other programs, up to a maximum depth of 4 (ex. B->C, C->D).
- The programs can "sign" on behalf of the PDAs derived from its program ID.

## References

https://solana.com/docs


build a strong understanding of the core concepts that make Solana different from other blockchains.