Blog¶

Simplified Explanation of Yonatan Sompolinsky's Research on Atomic Composability and L1/L2 Support for Kaspa

Hey everyone, welcome back to Coinchimp!
If you haven’t seen it yet, Yonatan Sompolinsky recently shared an insightful post on X: Link. The post dives into "Atomic Composability and Other Considerations for L1/L2 Support." It’s an exciting look at how Kaspa is improving smart contract solutions.

The paper is a bit technical, so here’s my simplified breakdown of what it all means and why it matters. Let’s start!

What is Atomic Composability?

At its core, atomic composability ensures that smart contracts can interact instantly and seamlessly. For example, if you’re using DeFi—swapping tokens and borrowing simultaneously—atomic composability means everything happens in sync, without delays or uncertainty.

Compare this to Ethereum or Solana today:
- Ethereum is moving towards rollups, where smart contracts often interact asynchronously, causing delays.
- Solana is faster but sacrifices decentralization to achieve its speed.

Kaspa’s goal is to combine speed, security, and decentralization, making interactions seamless and instant.

Practical Example: Multi-Step DeFi Lending on Ethereum

Let’s bring this to life with a scenario:
Imagine you’re taking out a loan on a DeFi platform. With Ethereum’s async composability, the system might need to process multiple transactions across rollups. This introduces several risks:

Delay Risks

Cross-rollup transactions aren’t instant. While your funds are safe, delays could mean missing opportunities, like securing a loan or completing a trade before a price changes. This is critical in fast-moving markets.

Increased Complexity

Async systems rely on messaging layers or bridges to transfer data between rollups and the base layer. If a bridge fails or there’s a delay, operations stall, leaving you waiting or forcing manual retries.

Cost of Failures

Even when transactions fail safely, you still lose gas fees. Paying for failed attempts due to async limitations can add up and frustrate users.

No Guarantees for Multi-Step Transactions

In async systems, each step executes independently. If one step fails—like locking collateral for a loan—the entire operation breaks down, requiring retries and more fees.

Smart Contract Safeguards

Ethereum platforms often use application-level safeguards to bundle operations, ensuring they succeed fully or fail entirely. But even this doesn’t fix the underlying delays or inefficiencies.

How Would It Work with Kaspa?

With Kaspa’s atomic composability, the experience is completely different:
- The loan is issued, collateral is locked, and tokens are transferred all at once in a single transaction.
- No delays, no uncertainties—it’s faster, more reliable, and user-friendly.

Here’s why:

All Actions Happen Instantly

Transactions across logic zones (smart contracts, rollups, etc.) occur in one atomic step. Either everything succeeds, or nothing happens—no partial execution.

No Intermediate Failures

You don’t have to worry about delays between rollups or partial failures. If any part of the transaction fails, the entire process is reverted automatically.

Seamless User Experience

Kaspa avoids reliance on messaging bridges or async confirmations, eliminating delays or dependent step failures entirely.

zk Rollups and Kaspa’s Role

Now, let’s connect this to zk rollups.
On Ethereum, zk rollups handle computation off-chain and send proofs to the base layer. But async composability creates challenges when syncing these proofs across smart contracts.

Kaspa solves this by ensuring zk rollups send their data and proofs on-chain. This keeps everything transparent, verifiable, and instant. No waiting for cross-zone transactions or missing data—making Kaspa a truly zk-proof-ready blockchain.

Why It Matters for Developers and Users

For Developers:
- Building apps becomes simpler. Imagine creating a DEX or lending protocol where all interactions are predictable and happen in one atomic transaction.
- No extra syncing layers or delays—just streamlined, reliable development.

For Users:
- The experience improves dramatically.
- Faster trades, no failed transactions, and no frustrating rollup delays. Kaspa’s approach creates a blockchain ecosystem that "just works."

Conclusion and Takeaway

To wrap it up, Kaspa is pushing the boundaries of blockchain with atomic composability. It’s bridging the gap between speed, security, and decentralization, making zk rollups and smart contracts seamless and efficient.

This is a huge step forward for developers and users, paving the way for a blockchain future that’s fast, reliable, and easy to use.

Cheers!

Kaspa Sparkle Seamless Smart Contracts and Business Logic Integration

Introducing Sparkle: Kaspa's Layer 1.5 for Seamless Smart Contracts and Business Logic Integration

In a prior discussion, an open video call on July 9th posted on Kaspa’s YouTube channel, Kaspa core developers, including Aspect, Shai Wyborski, and Yonatan Sompolinsky, considered two approaches for implementing smart contracts. One of the guests at this meeting was Ilia from StarkWare, an industry leader in ZK tech specializing in zero-knowledge rollups and ZK-VMs. Kaspa’s developers debated two paths forward: one option was to go fully native with Rust, aligning well with Kaspa’s speed and architecture, though it would take longer to build. The alternative was to integrate with established ZK ecosystems, like StarkWare's ZK-VM, to leverage pre-existing tools and smart contract compatibility.

Following this, a few days ago, Aspect presented a nearly 5-hour workshop at the Kaspa Innovation Summit in Hong Kong, introducing Sparkle as a solution for efficient ZK proof verification and zk-Rollups on Kaspa’s Layer 1. Sparkle integrates seamlessly with Kaspa’s BlockDAG, offering a flexible multi-state model, decentralized proofer incentives, and streamlined proofing scripts. Designed for low-resource use and requiring no hard fork, Sparkle enables scalable smart contracts on Kaspa.

In the latest Blockchain Banter, Aspect highlighted that Sparkle is a community-driven project being funded through KSPRbot. This support from KSPRbot enables Sparkle to be developed independently from Kaspa’s core development team, allowing it to explore new frameworks and integrate seamlessly with Kaspa’s technology while staying aligned with the community’s goals. Sparkle operates as a separate peer-to-peer network and is set for release next summer, with applications spanning various sectors, including gaming.

What Is Sparkle?

Sparkle is a sort of Layer 1.5 solution that integrates with the Kaspa BlockDAG. I say sort of Layer 1.5 because Aspect mentioned they want to keep Kaspa Network Fundamentals untouchable, adding an extra service offering a bridge between the base network (Layer 1) and more advanced Layer 2 functionalities. This unique positioning allows Sparkle to support a variety of smart contract features and business logic without the complexity and overhead of other blockchain platforms. Importantly, Sparkle operates independently of Kaspa's core development team and is funded by the community through the KSPRbot initiative, with a functional service targeted for Summer next year.

Key Goals of Sparkle: Empowering Businesses and Users Alike

Aspect emphasized that Sparkle’s design aims to serve a wide range of use cases, particularly in areas like gaming and decentralized finance (DeFi). The primary goals are:

1. Layer 1 ZK Proof Verification: Sparkle integrates ZK proof technology directly on Layer 1, allowing for zk-Rollups, which can bundle multiple transactions and validate them as a single proof.
2. User-Friendly Integration for Business Logic: By avoiding the complexities of existing smart contract frameworks, Sparkle makes it easy to implement custom logic. Businesses in industries like gaming can tailor their applications without being bound by traditional blockchain constraints.
3. Flexibility and Minimal Resources: Sparkle will work either as an extension to Kaspa’s core node or independently, allowing deployment on everyday devices without needing high computing power. This approach preserves Kaspa’s decentralized ethos.

How Does ZK Proof Work in Simple Terms?

ZK proofs are based on math—lots of math! The idea is that a "prover" (someone who knows the secret information) creates a mathematical proof that a "verifier" (someone who doesn’t know the information) can check. The verifier can confirm the proof without learning the actual secret.

A popular example is like a locked door. Imagine there’s a room with a secret code on the other side. You say, "I know the code," but you don’t want to tell me what it is. Instead, you go inside, unlock the door, and come out through another exit. I know you unlocked it, so I believe you, but I never learned the actual code.

How Sparkle’s Smart Contract Design Stands Out

Unlike traditional smart contracts, which can be heavy on resources and often require extensive development modifications, Sparkle is designed to fit seamlessly with Kaspa’s existing infrastructure. Here’s how:

• ZK Rollups for Efficiency: As I said before, ZK Rollups are Sparkle’s backbone for handling transactions efficiently. By allowing multiple transactions to be bundled into a single proof and verified on Kaspa’s Layer 1, ZK Rollups drastically reduce the computational load, enabling faster and more cost-effective transactions.

• No Disruptive Design: Sparkle functions as a middle ground, not quite Layer 2 but more advanced than typical Highly eficient Proof of Work Network operations. This sort of "Layer 1.5" approach offers a hybrid solution that maintains security without compromising scalability.
• No Hard Fork Required: Sparkle operates independently of Kaspa’s core BlockDAG and doesn’t require a major update to the base network. However, the upcoming Crescendo hard fork will provide additional support for Sparkle contributing with some of the requirements not provided today, helping to streamline its functionalities.

Core Components of Sparkle’s Smart Contract Infrastructure

1. State Management and Multi-State Model: Sparkle allows for a flexible multi-state model, where different aspects of a business application can run independently within the same environment. For instance, in a game, various in-game assets or states can be managed separately without needing to validate the entire state each time. This approach reduces verification time and helps optimize performance.
2. Proofer Ecosystem and Incentives: Sparkle introduces a multi-proofer system similar to Kaspa's PoW mining setup. Proofers are incentivized to verify transactions by including reward addresses, which promotes decentralized proof generation. This system is designed for first-come, first-served processing, promoting fair and distributed participation.
3. Payload-Based Proofing Scripts: Sparkle employs scripts that can support multiple state changes and include specific opcodes for ZK verification. This setup allows developers to structure proof requirements and interact with different states efficiently, ensuring a streamlined experience for Layer 1 and Layer 2 operations.

Future-Proof and EVM-Free

One key feature of Sparkle is its independence from Ethereum’s EVM (Ethereum Virtual Machine) standards. This design decision is intentional, allowing Kaspa to avoid the limitations, performance issues and fees associated with EVM-based networks. Sparkle is considering zkVM support to allow for future Layer 2 compatibility, ensuring that Kaspa can evolve alongside advancements in zero-knowledge technology without being constrained by existing standards.

What This Means for the Kaspa Community

Sparkle’s development is driven by the need to make advanced smart contract capabilities accessible to all. Its lightweight requirements mean it can run on standard devices without sacrificing decentralization or scalability. As a project funded by KSPRbot, Sparkle demonstrates the strength of community-driven innovation in the Kaspa ecosystem.

Looking Ahead: Sparkle’s Impact on Kaspa

With Sparkle, Aspect aims to make Kaspa a viable platform for high-performance applications, particularly in areas where decentralized applications are expanding, like gaming and finance. By integrating ZK proofs and a multi-state model on Layer 1.5, Sparkle is set to transform how developers and businesses approach decentralized solutions on Kaspa.

In summary, Sparkle represents a significant leap forward for Kaspa by: - Enabling seamless integration of custom business logic. - Supporting efficient, fast and low-cost ZK verification on Kaspa as Layer 1. - Maintaining the decentralized ethos of Kaspa through minimal resource requirements.

By Summer next year, Kaspa could be home to a truly accessible, efficient, and scalable smart contract platform, thanks to Sparkle. This project is a testament to what community-backed innovation can achieve, and it highlights the Kaspa network’s potential to redefine the landscape of decentralized applications.

Understanding KRC20 Minting with TypeScript Real Examples: A Step-by-Step Guide

Minting a KRC20 token can seem daunting, especially for newcomers in the crypto world. In this post, we'll walk you through the minting process using TypeScript code pieces as an example. Those code pieces are using rusty-kaspa WASM recommended by aspect. We'll also dive into the composition of transactions and discuss some updates on KIP-9, addressing current challenges and solutions.

Special thanks to KaffinPX for sharing this code in the dev channel inKaspa Discord server.

What is KRC20?

KRC20 is a standard for tokens on the Kaspa network, similar to the BRC20 standard for Bitcoin. It defines a set of rules for tokens, enabling seamless interaction within the Kaspa ecosystem.

Minting KRC20 Tokens: The TypeScript Example

Our TypeScript app leverages the Kaspa WASM SDK to mint KRC20 tokens. Here's a simplified explanation of the process:

Step 1: Setup and Create the Script

We create a script that includes the minting data for the KRC20 token:

import { ScriptBuilder, Opcodes, PrivateKey, addressFromScriptPublicKey } from "./wasm/kaspa"
import config from "./config.json"

const privateKey = new PrivateKey(config.treasury.privateKey)
const publicKey = privateKey.toPublicKey()
const address = publicKey.toAddress('testnet-11')

const data = { "p": "krc-20", "op": "mint", "tick": "TNACHO" }

const script = new ScriptBuilder()
  .addData(publicKey.toXOnlyPublicKey().toString())
  .addOp(Opcodes.OpCheckSig)
  .addOp(Opcodes.OpFalse)
  .addOp(Opcodes.OpIf)
  .addData(Buffer.from("kasplex"))
  .addI64(0n)
  .addData(Buffer.from(JSON.stringify(data, null, 0)))
  .addOp(Opcodes.OpEndIf)

const P2SHAddress = addressFromScriptPublicKey(script.createPayToScriptHashScript(), 'testnet-11')!

Step 2: Commit Transaction

The commit transaction is the first step in the minting process. This transaction locks funds into a Pay-to-Script-Hash (P2SH) address. The P2SH address is used to ensure that the script must be satisfied before the funds can be spent. This provides an additional layer of security and ensures that the minting operation can only be completed if certain conditions are met. Specifically, it means the funds are locked under a script that dictates how and when they can be spent, protecting against unauthorized or premature usage.

const { entries } = await RPC.getUtxosByAddresses({ addresses: [address.toString()] });
const { transactions } = await createTransactions({
  priorityEntries: [],
  entries,
  outputs: [{
    address: P2SHAddress.toString(),
    amount: kaspaToSompi("1")!
  }],
  changeAddress: address.toString(),
  priorityFee: kaspaToSompi("0.1")!,
  networkId: 'testnet-11'
});

for (const transaction of transactions) {
  transaction.sign([privateKey]);
  const hash = await transaction.submit(RPC);
}

In this step, we create and sign a transaction that sends 1 Kaspa to the P2SH address. This transaction is submitted to the network, effectively committing to the minting operation.

Step 3: Reveal Transaction

After the commit transaction is confirmed, we proceed with the reveal transaction. This transaction reveals the minting operation by spending the UTXO created in the commit transaction. The script is included in the reveal process to prove that the conditions for minting the KRC20 token are met.

The priorityEntries parameter includes the UTXO from the commit transaction as the highest priority for spending. This ensures that this specific UTXO is used first in the reveal transaction, which is essential because it contains the locked funds that are governed by the script we created.

setTimeout(async () => {
  try {
    const { entries } = await RPC.getUtxosByAddresses({ addresses: [address.toString()] });
    const revealUTXOs = await RPC.getUtxosByAddresses({ addresses: [P2SHAddress.toString()] });

    const { transactions } = await createTransactions({
      priorityEntries: [revealUTXOs.entries[0]],
      entries,
      outputs: [],
      changeAddress: address.toString(),
      priorityFee: kaspaToSompi("0.1")!,
      networkId: 'testnet-11'
    });

    for (const transaction of transactions) {
      transaction.sign([privateKey], false);

      const ourOutput = transaction.transaction.inputs.findIndex((input) => input.signatureScript === '');

      if (ourOutput !== -1) {
        const signature = transaction.signInput(ourOutput, privateKey);
        transaction.fillInput(ourOutput, script.encodePayToScriptHashSignatureScript(signature));
      }

      const revealHash = await transaction.submit(RPC);
    }
  } catch (revealError) {
    console.error('Reveal transaction error:', revealError);
  }
}, 20000); // Wait for 20 seconds before attempting to reveal

In the reveal transaction, we: 1. Identify the UTXO from the commit transaction. 2. Create a new transaction that spends this UTXO. 3. Include the script to verify that the conditions are met. 4. Sign and submit the transaction.

Why Use P2SH and Scripts?

Using a P2SH address allows us to lock the funds with a script that defines specific conditions for spending. This provides flexibility and security, ensuring that the minting process can only be completed if the defined conditions are met. The script execution happens when the reveal transaction is processed, verifying the minting conditions before allowing the UTXO to be spent.

Update on KIP-9 and Ongoing Challenges

KIP-9 introduces a mechanism to regulate the growth of the UTXO set, addressing state bloat in the chain. Our TypeScript app utilizes the createTransactions() function from Kaspa WASM SDK, which incorporates KIP-9 fee calculations and ensure your app is compatible with the extended mass formula proposed in KIP-9 to regulate the creation and lifecycle of UTXOs. However, two critical features are still in progress:

1. Dynamic Network Fee Estimation: This will allow for more accurate priority fee calculations based on current network conditions.
2. Replace-By-Fee (RBF): This feature will enable transaction replacement in the mempool with higher fees, ensuring timely confirmation.

These updates are expected to be available in the coming weeks, enhancing the efficiency and scalability of KRC20 token minting. Additionally, KIP-9 helps to make better block utilization by regulating the growth rate of the UTXO set and optimizing transaction fees, thus reducing state bloat and enhancing overall network performance.

KRC20 Tokenomics Explained: The Future of Fair Launches**

The rise of KRC20 tokens, introduced by the Kasplex Foundation, is revolutionizing the crypto landscape. These tokens bring flexibility to Kaspa via smart contracts and offer a transparent and fair approach to token launches, making them a game-changer compared to Solana and Ethereum. In this blog post, we'll explore how KRC20 tokenomics work and why they are becoming the preferred choice for new projects.

The Growth of KRC20 Tokens

KRC20 tokens are rapidly gaining popularity due to their unique approach to token distribution. Unlike traditional tokens on Solana or Ethereum, KRC20 tokens allow anyone to mint them. This open-access minting ensures a more equitable distribution, fostering a fair launch environment. In this model, 100% of the tokens can be mintable from the start, enabling a truly decentralized and fair distribution.

Fair Launch Options

One of the standout features of KRC20 tokens is the flexibility they offer in token distribution. While projects can opt for a fully mintable launch, there is also the option to pre-mint a portion of the tokens. This pre-minting allows project creators to reserve tokens for the team, marketing, or future exchange listings. Additionally, projects can decide the mint batches, even attempting to mint an amount equal to the entire supply. This approach, however, could lead to centralization if not managed properly, as creators could potentially control all the tokens.

Transparency and Public Information

All information about KRC20 token deployments is public. Tools like Kasplex and Kastools.com provide detailed insights into how tokens were distributed, who benefited, and how the community and project decisions have been managed. It's crucial to analyze this information to understand the project's dynamics and future potential.

Risks and Considerations

While KRC20 tokens offer a fair launch mechanism, there are risks to consider. For example, tokens quietly pre-minted by creators may lead to projects stalling if the team does not continue to push for exchange listings or further development. This could render the tokens useless in the future. Therefore, understanding the tokenomics and supply limits is vital.

Projects like Nacho, Kasper, and Kaspaw have implemented fair launch principles, but with different approaches to supply and limit ratios. Nacho's higher supply/limit ratio ensures a more stable and bot-resistant distribution but may reduce initial hype. In contrast, Kasper's lower ratio creates a more exciting minting process but is more susceptible to bot and whale manipulation. Meanwhile, projects like GhoadCoin pre-allocate a significant portion of tokens, leaving only 30% for community minting, which could impact decentralization.

The Power of Kaspa and KRC20

KRC20’s flexibility and fairness, combined with the speed and scalability of Kaspa, offer unprecedented benefits to the crypto community. Kaspa’s unique BlockDAG technology provides significant advantages over traditional blockchain systems. Unlike linear blockchains, BlockDAG allows multiple blocks to be created and processed simultaneously, resulting in higher throughput and faster transaction speeds. This scalability ensures that Kaspa can handle a large number of transactions efficiently, making it ideal for the growing demands of KRC20 tokens and other crypto projects.

Recommendations for Potential Investors

1. Verify the Source:

2. Ensure the Kasplex Foundation officially introduced KRC20 tokens for smart contracts and flexibility in Kaspa. Cross-check this with official documentation and announcements.

3. Understand Minting Details:

4. Familiarize yourself with the specific minting options available for each KRC20 token. Knowing whether a project has opted for full mintability or pre-minting will help you assess its fairness and decentralization.

5. Use Trusted Tools:

6. Regularly check tools like Kasplex and Kastools.com for up-to-date information on token distribution and project developments. These tools are essential for making informed decisions.

7. Analyze Project Tokenomics:

8. Look into the tokenomics of each project. Understanding supply/limit ratios and distribution methods will give you insights into potential risks and benefits.

9. Read the Whitepapers:

10. Always read the whitepapers of any project you consider investing in. These documents contain crucial information about the project's goals, tokenomics, and roadmap.

Conclusion

KRC20 tokens are paving the way for fairer and more transparent token launches. By offering open-access minting and flexible distribution options, they address many of the issues seen with traditional token launches on other platforms. Additionally, the integration of KRC20 tokens with Kaspa’s BlockDAG technology brings speed and scalability, offering unparalleled benefits to the crypto community. However, it's essential to carefully analyze each project's tokenomics and distribution plans to understand the potential risks and benefits. With the right information, KRC20 tokens can be a powerful tool for creating more equitable and decentralized crypto projects.

Revolutionizing Meme Coins: The Rise of Decentralized Fungible Tokens

The world of cryptocurrency is ever-evolving, and the next big leap is already here: decentralized mineable fungible tokens. These tokens promise to bring a new level of fairness and decentralization to the crypto space, particularly in the realm of meme coins. But what makes decentralized mineable or minted tokens so special, and how can they transform the way we launch new token projects? Let's dive in.

Kaspa Foundation's KRC20 Solution: A Step Forward in Crypto Fairness

The Kaspa Foundation is leading the charge with its innovative KRC20 standard. This standard allows anyone to mint tokens that have been deployed on their blockchain, providing a more fair and decentralized condition for any new token being launched.

However, there are always potential workarounds. While this is a significant step forward, individuals might still try to mint tokens quietly, leading us back to pre-allocation or presale models like those seen on Solana and Ethereum.

The Advantages of a Decentralized Mint Process

One of the key challenges in the crypto world is ensuring that new token projects are launched fairly and remain decentralized. Traditional token launches often face issues like pre-minting, centralized control, and lack of transparency. However, decentralized minted tokens offer a clear solution:

Community Trust: The most important aspect is trust. According to the KRC20 documentation, when a token is deployed on KRC20, you can define a max supply and the size of each batch.

Fair Launch: Anyone can participate in the minting process, ensuring that no single entity has control over the initial distribution. This levels the playing field and promotes a more democratic token economy.

Example of Fairness: Nacho the Kat

Consider our new meme coin, $NACHO. According to its tokenomics, when KRC20 is ready, they will deploy a max supply of 280 billion tokens, with a batch size of 287K. They will also define a start and end date for the process. The minting process will stop either when the max supply is reached or the end date arrives.

During this timeframe, everyone can mint batch by batch at the cost of one $KAS per mint process, yes, you hear well, on $KAS. It will take 1 million mint executions to reach the max supply before the end date. This ensures a fair and immediate distribution of tokens.

The next approach will introduce greater difficulty via Proof of Work (PoW), which will not only ensure fairness in distribution but also control inflation over time.

Introducing Radiant and the Photonic Wallet

Radiant offers an advanced solution that takes the concept of mineable tokens to the next level. Utilizing the Atomicals protocol, Radiant allows anyone to mine newly deployed tokens via a GPU miner integrated into a browser extension. Powered by a UTXO blockchain, Radiant combines Bitcoin's security and decentralization with the ability to scale to thousands of transactions per second using induction proofs.

Radiant is also on the verge of launching the Photonic Wallet, an open-source project that empowers any community to create their own mineable or non-mineable tokens with just a few clicks. This tool makes it easier than ever for communities to participate in the crypto space, ensuring fair and decentralized token creation.

An important difference is that Radiant controls the entire process end-to-end.

And you would ask yourself why Kaspa didn't do something like that Well, maybe because Kaspa and Kasplex (KRC20) are two different entities, and while their collaborative solution is fair, it would be challenging for Kaspa to adapt its "Kaspa stratum bridge" to support tokens from software that depends on another entity. From other point of view, I think is great that Kaspa can keep focus on doing their solution better and faster - they have almost 80% of their miners moved to Rust.

The Advantages of Mineable Tokens

Fair Launch: With mineable tokens, anyone can participate in the mining process, ensuring that no single entity has control over the initial distribution. This levels the playing field and promotes a more democratic token economy.

Decentralization: By utilizing a PoW consensus mechanism, mineable tokens inherit the security and decentralization features of established blockchains like Bitcoin. This means no central authority can manipulate the network, making it more resilient and trustworthy.

Security: PoW mineable tokens are secured by computational power, making it extremely difficult for malicious actors to attack the network. This enhances the overall security of the token and the underlying blockchain. Additionally, Radiant controls all software components, making it easy for anyone to mine and mint them.

Conclusion

All the elements are now in place for any community to test and adopt these innovative solutions, making the crypto world a fairer and more decentralized place—even for meme coins or coins offering utilities. With PoW mineable tokens and the power of Atomicals protocols, the future of cryptocurrency is brighter, more secure, and more accessible to everyone.

Stay tuned for more updates on these exciting developments, and get ready to participate in the next big thing in crypto!

Cheers

Additional Information

• Kasplex Documentation
• Radiant Photonic Wallet
• Radiant Blockchain Site

How to Deploy Razoo's Photonic Wallet on Google Cloud Run

Hello everyone! I’m excited to share my latest adventure – setting up Razoo’s Photonic Wallet on Google Cloud Run. This wallet isn’t just for sending and receiving tokens; it allows you to create new tokens, including mineable meme tokens. It’s fair, secure, and efficient, thanks to Radiant's induction proofs. Let's dive into the details!

Step 1: Setting Up the Dockerfile

Here’s the Dockerfile that you’ll need to build the Photonic Wallet image:

FROM node:18
RUN npm install -g pnpm
RUN git clone https://github.com/coinchimp/photonic-wallet
WORKDIR /photonic-wallet
RUN pnpm install
RUN pnpm build
RUN npm install -g http-server
EXPOSE 8080
CMD ["http-server", "/photonic-wallet/packages/app/dist", "-p", "8080"]

If you’re running it locally with self-signed certificates, use this Dockerfile:

FROM node:18
RUN npm install -g pnpm
RUN git clone https://github.com/coinchimp/photonic-wallet
WORKDIR /photonic-wallet
RUN pnpm install
RUN pnpm build
RUN npm install -g http-server
RUN mkdir -p /photonic-wallet/certs && \
    openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /photonic-wallet/certs/selfsigned.key -out /photonic-wallet/certs/selfsigned.crt -subj "/C=US/ST=State/L=City/O=Organization/OU=Unit/CN=localhost"
EXPOSE 8080
CMD ["http-server", "/photonic-wallet/packages/app/dist", "-p", "8080", "-S", "-C", "/photonic-wallet/certs/selfsigned.crt", "-K", "/photonic-wallet/certs/selfsigned.key"]

Step 2: GitHub Actions Workflow

Here’s the workflow file to automate the build and deployment process to Google Cloud Run:

name: Deploy Photonic Wallet to Google Cloud Run

on:
  push:
    branches:
      - master

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v2

      - name: Log in to Google Container Registry
        uses: docker/login-action@v2
        with:
          registry: gcr.io
          username: _json_key
          password: ${{ secrets.GCP_RUN_CREDENTIALS }}

      - name: Build and push Docker image
        uses: docker/build-push-action@v3
        with:
          context: .
          file: ./Dockerfile
          push: true
          tags: gcr.io/${{ secrets.GOOGLE_PROJECT_ID }}/photonic-wallet:${{ github.sha }}

      - name: Authenticate to Google Cloud manually
        env:
          GCP_JSON_KEY: ${{ secrets.GCP_RUN_CREDENTIALS }}
        run: |
          echo "$GCP_JSON_KEY" > /tmp/gcp-key.json
          gcloud auth activate-service-account --key-file=/tmp/gcp-key.json

      - name: Set Google Cloud Project
        env:
          GCP_PROJ_ID: ${{ secrets.GOOGLE_PROJECT_ID }}
        run: gcloud config set project "$GCP_PROJ_ID"

      - name: Verify Authentication
        run: |
          gcloud auth list
          gcloud config list project

      - name: Deploy to Google Cloud Run
        run: |
          gcloud run deploy photonic-wallet \
            --image gcr.io/${{ secrets.GOOGLE_PROJECT_ID }}/photonic-wallet:${{ github.sha }} \
            --platform managed \
            --region us-central1 \
            --allow-unauthenticated
        shell: bash

Step 3: Setting Up Google Cloud Run

Before deploying, make sure to create an instance in Cloud Run and set the necessary permissions:

1. Create an Instance:
2. Go to the Google Cloud Console.
3. Navigate to Cloud Run and create a new service.

4. Choose your region and the container image URL (from Google Container Registry).

5. Set Permissions:

6. Ensure the Cloud Run service account has the following roles:
   • Cloud Run Admin
   • Storage Admin
   • Artifact Registry Reader
7. You can set these permissions in the IAM section of the Google Cloud Console.

Conclusion

That’s it! You’ve successfully deployed Razoo’s Photonic Wallet to Google Cloud Run. For more details, check out the Photonic Wallet repo. Happy deploying and enjoy creating your own tokens!

Cheers

Exploring the Exciting World of Radiant

I have been a big fan of projects like Kaspa. These chains offer incredible potential, and I have seen a lot of hype surrounding KRC20, which is still in development. People are excited about the possibility of creating meme coins, but I hope it will also attract other projects with more utility.

However, did you know there are other highly scalable projects?

The Technical Excellence of Radiant Community

Although it has a small community yet, it is very focused on technical excellence. Radiant is very close to completing the Photonic Wallet. This wallet will enable the creation of PoW mineable coins, promoting decentralization and fair launches.

Why PoW Fungible Tokens Are Superior?

Proof-of-Work (PoW) fungible tokens offer significant advantages over tokens minted on platforms like Ethereum and Solana. If you're aiming for a project that is everlasting, trustless, fair-launched, and fully decentralized, PoW tokens are the way to go - even for a meme!

1. Trustless: With PoW, transactions and token creation are verified by miners who follow strict cryptographic rules. This eliminates the need for trust in a central authority, making the system more secure and reliable.

2. Fair-Launched: PoW tokens are distributed through mining, meaning anyone with the right hardware can participate from the start. This contrasts with pre-mined tokens on other platforms, where early insiders often have a significant advantage by managing vesting schedules.

3. Community-Driven: The PoW mechanism relies on a network of independent miners spread across the globe. This decentralization reduces the risk of a single point of failure or control, ensuring the network is more resilient and censorship-resistant.

PoW fungible tokens provide a more robust foundation for projects that prioritize security, fairness, and decentralization. They stand out as the best choice for creating a truly democratic and enduring project.

How it works

Radiant stands out as the only fork or layer 2 project related to Bitcoin that can create this type of coin using atomicals. It also offers the unique Radiant feature of Induction Proofs, allowing tokens to be tracked back to the genesis block without using external indexers, making it fully trustless.

If you want to give it a try, you will need to install your own ElectrumX instance. You can use the publicly available Docker image by running the following command:

sudo docker run -d -v /home/pinrojas/electrumx_radiant:/data -p 8000:8000 radiantcommunity/electrumx_radiant_node:latest

After that, you can clone the same project. I did a fork to add an extra switch to the command electrumx_rpc. Run:

electrumx_rpc getinfo

You should see something like this:

{
    "coin": "Radiant",
    "daemon": "localhost:7332/",
    "daemon height": 197575,
    "db height": 187407,
    "db_flush_count": 21,
    "groups": 1,
    "history cache": "0 lookups 0 hits 0 entries",
    "merkle cache": "0 lookups 0 hits 0 entries"
}

If you are not familiar with UTXO, you need to wait for the daemon height and db height to be the same to ensure your server is in sync.

Then, clone Photonic Wallet and start playing with your new pizza or pepe-rxd tokens (I am on that phase right now, I will give you more insigths as soon as I can)

Check out Radiant Blockchain for more details.

Cheers!

Diving Into a World of Coding and Crypto: My Journey Begins

Hello everyone, and welcome to the very first blog post on CoinChimp! I'm thrilled to kick off this adventure where I'll be sharing everything I learn along the way. Whether you're a seasoned coder or just dipping your toes into the crypto waters, I hope you'll find something useful here.

Starting with Rust

My coding journey has taken a new turn—I've started exploring Rust! After dabbling in Python and Go, I noticed Rust's rising popularity, not just in the tech community but especially in the crypto space. It’s an exciting change, and I'm eager to dive deeper.

Automating Discord Alerts

Recently, I launched my first application—a simple yet effective tool to automate alerts on Discord. Using a webhook service on Google Cloud Run, I managed to simplify what initially seemed a daunting task. This experience was not just about coding; it was about bringing my entire toolkit into play. From containers and Kubernetes to integrating ChatGPT for faster coding without sweating over syntax, every bit of my tech background helped streamline the process.

Learning on the Fly

The journey wasn’t smooth from the start. I initially tried using Discord’s developer portal to register an app but soon realized managing tokens and redirect links was getting too complex. Switching to webhook integrations simplified everything, allowing me to quickly wrap up my first version.

Another major leap was utilizing GitHub Actions, which seamlessly pushed my code changes to a live service on Google Cloud Run. It's impressive how much insight one can gain from GitHub's logs—they really make debugging a breeze.

TradingView and Family Crypto Adventures

My project allowed me to send TradingView alerts directly to my personal server, simplifying how I track market movements. This not only cuts down the clutter of phone notifications but also lets me share insights with my wife, a brilliant mind in the crypto world. Together, we're navigating this fascinating era of financial innovation.

The Bigger Picture

Exploring cryptocurrencies like Bitcoin, Kaspa, and Radiant has been enlightening. Their underlying technologies fascinate me—the decentralized networks, the complex algorithms, and the way they ensure transparency without a central authority. It’s a testament to how blockchain can safeguard not just financial transactions but potentially any valuable data across industries.

Looking Ahead

While many coins may not withstand the upcoming bear market, the knowledge and technologies we develop will pave the way for future applications. This isn't just about investments—it's about understanding and possibly revolutionizing how we interact with digital information.

I'm excited about where this journey will take me, and I hope to turn this passion into a sustainable livelihood. Here's to the many learnings and shared experiences ahead!

Cheers to new beginnings!