Forem: Adetayo Lasisi

createthings — A Creative System Built on Notion MCP

Adetayo Lasisi — Sun, 29 Mar 2026 15:38:42 +0000

This is a submission for the Notion MCP Challenge

There is a folder on almost every creative's computer.

Sometimes it is a bookmark list. Sometimes it is a Pinterest board, a Notion page, a camera roll full of screenshots, or a browser tab that has been open for six weeks. The contents are always the same: things they loved when they found them and have not touched since. Landing pages to be studied. Threads that made them stop scrolling. Interfaces they meant to reverse-engineer. Designs they were going to recreate on the weekend.

The weekend never comes.

I built createthings because I got tired of my own inspiration graveyards.

Also, the more I talked to designers, developers, and content creators, who are my friends and colleagues, the more I realized the graveyard was not the core problem. The core problem was that saving something and acting on it had no connection. There was no bridge between the moment of being inspired and the moment of doing something about it. No thread between the thing that excited you and the work that came out of it. No record of the journey from one to the other.

What I built

createthings is a creative system for designers, developers, and content creators. It lives across two surfaces: a browser extension that captures inspiration from anywhere on the web, and a web app where that inspiration gets analyzed, understood, acted on, and shared with the world.

The core loop is straightforward to describe:

Capture what excites you — a screenshot, a URL, an uploaded image, or even a typed note when the inspiration is more feeling than visual. Analyze it with AI — not just what it looks like but what makes it work, what you can learn from it, what skills it requires. Think through your process in a creative journal tied to every project. Create your own version with an AI-generated brief as your starting point. Publish it to your connected social platforms directly from the app with platform-specific captions and proper credit to the original creator. Share your full creative journey via an auto-generated public portfolio page.

Notion is the backbone of all of it.

I made a deliberate decision early in the build. I did not want Notion to be a sync target or a convenient place to dump data. I wanted it to be the actual brain of the system, the place where everything lives, where the AI pipeline is triggered, where results are written, where the publish queue is managed, and where the portfolio reads from. Every piece of inspiration lives in Notion.

Video Demo

The code

adetyaz / create-things

createthings — A Creative OS Built on Notion MCP

This is a submission for the Notion MCP Challenge

Developing

npm install
npm run dev

Copy .env.example to .env and fill in:

NOTION_CLIENT_ID + NOTION_CLIENT_SECRET + NOTION_REDIRECT_URI — Notion OAuth app
GEMINI_API_KEY — Google AI Studio
GROQ_API_KEY — Groq console
OPENROUTER_API_KEY — OpenRouter (free-tier vision fallback)
PUBLIC_UPLOADCARE_PUBLIC_KEY + PUBLIC_UPLOADCARE_CDN_BASE — Uploadcare dashboard
WEBHOOK_SECRET — any random string, must match what you set in the Notion automation
FIGMA_ACCESS_TOKEN — Figma personal access token (optional)

Building

npm run build
npm run preview

There is a folder on almost every creative's computer.

Sometimes it is a bookmark list. Sometimes it is a Pinterest board, a Notion page, a camera roll full of screenshots, a browser tab that has been open for six weeks. The contents are always the same: things they loved when they found them and have not touched since. Landing pages they…

View on GitHub

Disclaimer
The web extension hasn't been approved by the Chrome Web Store, but I have the build available for testing here👈🏿

Installaion

Open the browser and go to chrome://extensions
Enable Developer mode (toggle in the top-right)
Click Load unpacked
Select your extension's folder

Who It Is For

createthings is built for three types of creators, and the experience adapts to each:

Designers can get a color palette extraction, typography identification, layout and composition breakdown, component analysis, and a Figma export that sends any captured screenshot directly to their Figma workspace as a named frame.

Developers get UI architecture hints, pattern recognition, likely tech stack indicators, and component structure breakdown, the things you want to know when you see an interface you admire and want to understand how it was built.

Content creators get hook analysis, tone breakdown, narrative structure identification, and an explanation of why a piece likely performed well — the things that turn a saved post into a teachable moment.

These three types of creators serve as the starting point, as i still intend to expand to different types of creatives, allowing it to be useful to everyone and anyone

The Feature Set

Feature	What It Does
Browser extension	Captures via URL, screenshot (full page or selected area), image upload, URL paste, or typed note
AI analysis	Visual and content breakdown — colors, typography, layout, mood, components, attribution
Learning roadmap	AI-generated skill path from the analysis — what you need to learn to build something like this
Creative journal	Per-project thought space with AI reflection prompts
Publish queue	Platform-specific captions drafted by AI — direct share to Twitter/X, LinkedIn, Reddit; one-click copy for Instagram
Remix tagging	Inspired by / Remixed from / Recreated — ethical attribution built into every publish
Figma export	Sends captured screenshots to Figma as named frames
Portfolio page	Auto-generated public page from Notion data, shareable via single link
Stale reminders	Smart nudges for inspiration that has been sitting untouched past a threshold
Weekly digest	Summary of what was saved, created, published, and learned

The Technical Architecture

Stack: SvelteKit + Svelte 5 (web app + API), Manifest V3 browser extension (Chrome/Firefox/Edge/Safari), Notion as the database layer (six linked databases), Uploadcare for image uploads.

AI: Gemini 2.0 Flash for visual analysis with a fallback chain (→ gemini-2.0-flash-lite → gemini-1.5-flash-8b → OpenRouter free vision → Groq text-only). Groq (llama-3.3-70b-versatile) handles all text generation, roadmaps, captions, and note analysis.

Data flow:

Extension saves a new entry to Notion (status: Pending) — that's all it does.
A Notion database automation fires a webhook to /api/webhook/notion.
The server routes by capture type: images/URLs go to Gemini (with node-vibrant extracting colors first); notes go straight to Groq.
Results are written back to Notion via the MCP adapter; status updates to Ready.

For publishing: captions surface in the Publish Queue. Twitter/LinkedIn/Reddit open compose URLs pre-filled; Instagram copies to clipboard. Clicking Mark Published updates the Notion entry.

The Six Databases

On first connect, all 6 Notion databases are created in one pass to get their IDs, then a second pass links the relations between them — because you can't create a relation to a database that doesn't exist yet.

Database	Purpose
Inspiration Vault	Every saved piece — the source of truth
Analysis Results	AI breakdown linked to each inspiration
Roadmaps	Learning paths generated from analyses
Projects	Work created — linked to inspirations
Publish Queue	Drafted and approved social posts
User Profile	Preferences, platform connections, Creative DNA

Technology Choices

AI: Gemini 2.0 Flash for vision (generous free tier, reliable structured output) with a 4-model fallback chain so the pipeline survives rate limits. Groq for all text generation because speed matters llama-3.3-70b-versatile keeps roadmap generation under 15 seconds.

Social publishing: Compose URLs instead of OAuth integrations — Twitter, LinkedIn, and Reddit accept pre-filled content as URL params, no API approval needed. Instagram has no compose URL so it falls back to clipboard copy. Ship with what works now, add direct API integrations when you have approvals.

How I Used Notion MCP

I made a rule early in the build: Notion should be the brain of the system, not a sync target. Every intelligent write-back goes through an MCP adapter layer — a set of functions in src/lib/server/notion/mcp.ts that wrap the Notion SDK calls for all agent actions.

The distinction between the REST API layer and the MCP layer is intentional. The REST API handles database operations: creating structure, querying records, and managing schemas. The MCP layer handles agent actions: an AI system reading context from a workspace and writing back purposefully — the same pattern a person working inside Notion would follow.

The Specific Operations

writeAnalysisResults — called after every analysis completes. Creates a page in the Analysis Results database with the full breakdown — color palette, typography notes, layout analysis, mood tags, component identification, attribution — and links it back to the source inspiration entry.

createRoadmap — called when a user requests a roadmap. Creates a structured Notion page in the Roadmaps database — not just a database row, but a full page with sections, skill descriptions, milestone checkboxes, and resource links. The page is created with the correct parent relation to the source inspiration, so the connection is permanent and navigable.

writePublishDrafts — called by the caption generation pipeline. Writes platform-specific captions to the Publish Queue entry — Twitter, LinkedIn, Instagram, Reddit — all with the credit line assembled from the stored attribution data.

updateInspirationStatus — moves entries through their lifecycle: Pending → Ready → Active → Stale → Archived.

Why a Dedicated MCP Layer

This is the question worth answering directly.

When the AI system writes results back to Notion, it is not inserting records — it is making decisions: what to name the page, how to structure the sections, which properties to set, what relations to create, how to format the skill descriptions so they are useful when the user opens the page later. That is an agent action. The MCP layer is the right abstraction for it. The REST API would require pre-specifying every structural decision in code. The MCP layer lets those decisions happen in context.

Having a clean adapter layer also makes the path to the hosted Notion MCP remote server straightforward. Every call goes through one place. The connection is established once per user session with their OAuth token and reused across all operations.

What I Learned

The hardest part was not the AI integration. It was the database setup order.

Notion relations between databases require both databases to exist before you can create the relation. That sounds obvious until you are writing the setup script at 1am and realize you cannot add the relation from Inspiration Vault to Analysis Results until Analysis Results exists — but you also cannot add it to a database you have not created yet. The solution was simple once I saw it: create all six databases first, collect their IDs, then make a second pass to patch the relations in. Two API calls where I wanted one. Not elegant but reliable.

The social API reality was the other hard lesson. I knew Instagram Graph API required Facebook app approval. I knew Twitter/X v2 could take time. What I underestimated was how much value there is in the compose URL approach first — x.com/intent/post, linkedin.com/shareArticle, reddit.com/submit. The user sees exactly what they are about to post. There is no abstraction between the caption and the publish. Add the server-side API integrations when you have time and approvals; start with the compose URLs and let the user be in control.

The thing that surprised me most was the note capture.

I almost cut it three separate times. It felt like scope creep. A text input in a browser extension — what problem does that solve that a notes app does not? I kept it because the use case would not leave me alone: what do you do when the inspiration is not a URL or an image? What do you do when you are in a meeting and you think "I want to make something that feels like the opposite of corporate" and you want to capture that before the meeting ends and you forget?

I also learned that the creative journal resonates more with experienced creators than with beginners. Beginners want to capture and analyze. Experienced creators want to document their process because they know the process is the portfolio, not just the output. That insight is shaping how I think about onboarding — meeting users where they are rather than assuming everyone is ready for the same features at the same time.

FitTogether: Building a Social Community for Local Fitness

Adetayo Lasisi — Mon, 02 Mar 2026 03:27:04 +0000

This is a submission for the DEV Weekend Challenge: Community

The Community

In a fitness world that often feels overcrowded yet socially disconnected, the power of a functional community is easily overlooked. Building FitTogether wasn't just about physically crowding people into a gym; it was about fostering a shared intelligence that makes these spaces easier to navigate for everyone.

From my personal experience, going swimming every weekend and regularly visiting the gym, I have noticed a noticeable difference in people's energy levels. This variation is especially apparent during times when the places are overcrowded compared to when there is more space available.

When new members join the gym, they tend to struggle to navigate, especially during busy hours. It can be overwhelming. This highlights the importance of creating an inclusive community that welcomes people of different personality types.

What I Built

I built FitTogether, a full-stack SvelteKit application that acts as a real-time "busyness" tracker and buddy-finding network.

The core pillars of the app include:

Live Crowdsourcing: A "Waze for Gyms" where users report capacity levels (Low, Medium, or High) to help others decide when to head out.
Privacy-First Buddy Finder: A sophisticated matching system where contact info (WhatsApp) is only revealed if both users are connected and currently active at a venue.
Gamified Challenges: A leaderboard system to keep users motivated, from swimming 5km a week to hitting "Weekend Warrior" streaks.
Interactive Geo-Data: A custom map interface using OpenStreetMap to visualize local fitness hubs and their current "traffic" status.

Demo

Code

Github Repo and Walkthrough Demos

adetyaz / fittogether

https://fittogether-five.vercel.app/

FitTogether

A community web app for local swimmers and gym-goers — crowdsourced busyness reports, buddy matching, and fitness challenges, built with SvelteKit.

Walkthrough Videos

Video	Description
Overview	Full app walkthrough
Pool and Gym Discovery with busyness levels	Crowdsourced busyness reporting
Buddies Connect	Buddy matching and messaging
Challenges and Logging Data	Fitness challenges & workout logging

What It Does

Crowdsourced Busyness — See how busy your local pool or gym is right now. Check in and report busyness levels (Low/Medium/High) with visual indicators, interactive Leaflet maps, and place search via Nominatim.
Buddy Finder — Find workout partners filtered by activity (swim/gym) and schedule (morning/evening/weekend). Send buddy requests, and contact accepted buddies via WhatsApp — but only when they've set themselves as active at a venue (anti-harassment by design).
Fitness Challenges — Join challenges like "Swim 5km in a Week", log workouts, track progress with visual bars, and compete on per-challenge leaderboards.

…

View on GitHub

How I Built It

The build centered on creating a high-performance, type-safe pipeline from a serverless PostgreSQL database using Neon to a full-stack frontend built on SvelteKit and Svelte, and, lastly, TailwindCSS for styling.

Data Architecture (Prisma & Neon)

I began by modelling the social and spatial relationships using Prisma. The schema handles four primary domains:

Spatial Data: Locations mapped with latitude and longitude for Leaflet integration.
Social Graph: A self-referencing BuddyRequest model to manage pending, accepted, and rejected states between users.
Real-time Status: A CheckIn system linked to locations, calculating the freshness of busyness reports via timestamps.
Gamification: ChallengeEntry and WorkoutLog tables to track incremental progress toward fitness goals.

The Privacy-First Logic Flow

A core technical requirement was the "Anti-Harassment" contact system. I built a server-side check that ensures a user's WhatsApp number is never sent to the client unless two conditions are met:

A BuddyRequest exists with a status of 'accepted'.

The target user has their activeStatus set to at_gym or at_pool.

// Logic gate for contact visibility const canContact = buddyStatus === 'accepted' && targetUser.activeStatus !== null;

Geocoding & Mapping

Instead of a paid API, I integrated Nominatim for place search. When a user searches for a gym, the app fetches coordinates, saves the new Location to the database via a SvelteKit server.ts action, and immediately updates the global map state without a page reload.

Challenge & Progress Tracking

The tracking system uses a background calculation to compare WorkoutLog totals against the Challenge goal value. This progress is visualized, rendering progress bars that update in real-time as users log their sessions.

User Stories (Summary)

Busyness

View locations with busyness levels, check in to report, see timestamps, browse an interactive map with color-coded markers, search & add places, see visual crowding indicators, and view location detail pages.

Buddy Finder

Set profile preferences, browse & filter users, write a bio, send/accept/decline buddy requests, see connection status, contact accepted buddies via WhatsApp (only when active), toggle active status (At Gym / At Pool / Offline), and see green dot indicators for active users.

Challenges

Browse challenges with participant counts, join challenges, log workouts, view leaderboards, and track progress with visual bars.

Profile & Auth

Safety

WhatsApp is hidden until the buddy request is accepted AND the user is active, reject unwanted requests, and go offline anytime to stop contact.

Let's begin the year with a bang!!

Adetayo Lasisi — Sat, 31 Jan 2026 17:15:17 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI

About Me

I’m a frontend engineer who is slowly transitioning into a design engineer. I decided to use this medium to create an experience. For 2026, I wanted to build something that felt authentically "me". After scouring Dribbble and Behance for inspiration, I dove into Figma and started putting things together. I wanted this to be simple yet have playfulness in it

Portfolio

How I Built It

Tech Stack

Sveltekit and Svelte
Gsap for animations
HTML & Vanilla CSS for structure and styling
Lenis for scroll smoothing
Lottie animations
The Repository

My development process was a collaboration between my creative vision and Antigravity.

Visual Grounding: I started by designing a mental structure in Figma. Instead of manually coding every layout detail, I used my design images and prompted Gemini Pro. I asked, "Can you convert this visual style into a functional website structure?" By the way, I was just trying things out at this point, but I was surprised by the scaffolding that happened
The Antigravity Environment: To achieve the fluid motion I envisioned, I collaborated with Gemini on my use of GSAP and Lenis, focusing on creating a way for these tools to be used efficiently, ensuring they were integrated at the root level rather than being called multiple times. This deliberate structure kept the styling and animations lightweight.
Iterative Blueprinting: One of my favourite parts of using Antigravity was the Implementation Plan. Gemini generated a .md file breaking down every step. This allowed me to interject, provide my own opinions, and tweak the logic before a single line of code was finalized.
The Human Touch: While the use of AI provided a stellar starting point and handled the heavy lifting of the initial structure, I spent my time fine-tuning the code. It wasn't 1-to-1 perfection immediately, but having that solid foundation allowed me to focus on making necessary tweaks and adding a little bit of personality to my portfolio website

What I'm Most Proud Of

I was able to get the build actually match the vision in my head. Throughout this process, I was so inspired by the progress that the ideas just kept flowing. While I pushed the boundaries of what I could do on the UI, I refused to compromise on the fundamentals, ensuring the site is accessible to everyone and remains perfectly responsive across all devices.

I didn’t want a bland, static site. I’ve hidden several interactive easter eggs throughout the portfolio to make the discovery process fun for visitors. It’s an invitation to explore.

I successfully modularized my animation libraries (GSAP and Lenis). By centralizing their logic, I was able to achieve performance, leaving the site feeling weightless and fluid, just like the design intended

Overall, seeing my personal vision transition from a mental structure in Figma to a live, functional site is a huge win for my 2026 goals.

カイアアジアのオンチェーンの未来

Adetayo Lasisi — Wed, 19 Feb 2025 18:45:01 +0000

この記事では、カイアの基礎技術、ユーザーフレンドリーなカイア・ポータル、カイア・チェーン内でのユーザー参加とエコシステムの成長を促すためのインセンティブなど、カイアの世界を掘り下げていく。

はじめに

Kaiaは高度に最適化されたBFTベースのパブリック・ブロックチェーンで、エンタープライズ・グレードの信頼性と性能基準を満たしている。カカオとLINEがそれぞれ開発したKlaytnブロックチェーンとFinschiaブロックチェーンの統合により誕生した。カイアは、アジア全域の何億人もの指先にWeb3をもたらします。

BFTベースのパブリック・ブロックチェーンとは？

これはビザンチン・フォールト・トレランス（BFT）を利用したブロックチェーンである。これにより、一部のノードが故障したり悪意のある行動をとったりしても、確実にコンセンサスに達することができる。このシステムは、ネットワークの完全性を損なうことなく、最大で!のノードが不正または不誠実な行動を取っても対処できるように設計されたアルゴリズムに依存している。パーミッションレス・ブロックチェーンよりも安全で、パフォーマンスも優れている。

BFTは腐敗を防止し、ネットワークの安全性と信頼性を維持するのに役立つため、パブリック・ブロックチェーンにとって極めて重要である。BFTがなければ、ネットワーク参加者が偽の情報を持ち込む可能性がある。

カイアの特徴と狙い

カイアはブロックチェーンを提供する：

1秒間のブロック生成と確認時間。
毎秒4,000トランザクションの処理能力。
イーサリアムの約1/10の低ガス価格。
EVM（イーサリアム仮想マシン）の互換性、Solidityコントラクトのサポート。
カイア・ガバナンス・カウンシルを設立する世界の評判の高い企業によるガバナンス

カイア・ブロックチェーンが目指すもの：

取引の即時確定を実現する。
実際のユースケースに対応した高速トランザクション処理を提供。
ブロックチェーン・アプリケーションの実行コストを下げる。
エンドユーザーの参入障壁を減らす。
様々な産業への技術導入を容易にする。

カイアのエコシステム

カイアのエコシステムは、分散型金融（DeFi）をシンプルでアクセスしやすく、規制を遵守した安全なものにするために構築されています。トークンのステーク、暗号の取引、異なるブロックチェーン間での資産の移動など、カイアはシームレスな体験を提供します。エコシステムの中核となるコンポーネントは以下の通りです：

カイア・ポータルカイア・ポータルは、ステーク、スワップ、リワードの獲得が一度にできるメインハブです。直感的に操作できるように設計されているので、DeFiが初めての方でも、経験豊富なプロの方でも、簡単にナビゲートできます。金融ツールを使いやすく、誰もが利用しやすいものにすることが目標だ。
ステーキング KAIAトークンをステークすることは、単に報酬を得ることではなく、ネットワークを強化しながら稼ぐことができ、ブロックチェーンの安全性を保つことにも役立ちます。KAIAトークンをロックアップすることで、バリデーターをサポートし、ネットワークを保護し、ステーク額と期間に応じてステーク報酬を得ることができます。
ブリッジング：カイアの際立った特徴のひとつは、異なるブロックチェーン間で資産を移転できるクロスチェーンブリッジだ。ブリッジングとは、暗号通貨やNFTのような資産やデータを異なるブロックチェーン・ネットワーク間で移転するプロセスを指す。例えば、ある国の銀行口座にお金があり、それを別の国で使いたいとします。ブリッジングは、国境を越えた安全かつ効率的な送金方法です。Kaiaの相互運用性は、ユーザーが1つのブロックチェーンだけに制限されることなく、DeFi空間全体の機会を利用できることを意味する。
分散型取引所（DEX）：カイアはDragonSwapやKaiaswapのような分散型取引所を統合しており、銀行や第三者を介さずに、ウォレットから直接暗号通貨を取引することができます。

DragonSwap：流動性の高い高速DEX。

カイアスワップ効率性に最適化された低手数料の取引プラットフォーム。

これらのプラットフォームは、ユーザーが資産を完全にコントロールできるようにする一方、取引を迅速かつ安全にし、手数料を引き下げる。

これらのプラットフォームは、取引を迅速、安全、かつ費用対効果の高いものにすると同時に、ユーザーが資産を完全にコントロールできるようにする。

カイア・ポータルに飛び込んで、そのエキサイティングな機能を発見してみよう。

カイア・ポータル

カイアでは、DeFiからオンチェーンゲームやNFTに至るまで、シームレスなWeb3ユーザー体験を提供することを最優先しています。ユーザーエクスペリエンスは、暗号に精通している人だけでなく、誰もがWeb3のメリットを享受できるようにするために不可欠であると強く信じています。高速でユーザビリティの高いレイヤー1ブロックチェーンの開発に加え、カイアは鍵管理の必要がないメッセンジャーウォレットを開発しました。

カイア・ポータルのユーザーフレンドリーなインターフェースは、デスクトップ、モバイル、そして近々LINEメッセンジャーでも利用できるようになる。DeFiの一般的な機能に加え、ポイントベースの報酬システムが間もなく追加され、新旧ユーザーがカイアDeFiおよび広範なエコシステムのミッションに参加することで報酬を得ることができる。

カイア・ポータルのミッションのエポック1では、カイアのDeFiパートナーを活用することで、魅力的なトークン報酬の機会が配布された。

続くエポック2では、カイアウェーブ・プログラムに関わるミッションに参加したユーザーは、魅力的な報酬を受け取ることができる。

カイアには、ビルダー、デベロッパー、パートナーなど、ユーザーにインセンティブを与える方法が他にもあり、エコシステムを構築している。

カイア・ポータル・ミッションエポック#1 インセンティブデザイン

エポック#1のミッションは2024年12月25日午後3時(UTC+9)に終了しましたが、エポック#2で何が起こり、何を楽しみにしているのか、その概要をお伝えしたいと思います。これは、Kaiaエコシステム内の流動性とユーザーエンゲージメントを高めるために設計されました。参加プロジェクトとともに、最大5000万KAIAトークンが割り当てられました。ミッションを成功裏に完了すると、参加者はポイントを獲得し、エポック終了後に既得のKAIAトークンとプロジェクト・トークンに変換することができます。

エポック1では、カイア・デフィのプロトコルに流動性を提供することがミッションの中心で、報酬は次のようなものだった：

カイアポイント
参加プロジェクトのポイント
D2Iプログラムの報酬
DeFiプロトコルによる収量

目標は、カイア上に新しいアプリケーションとDeFiユースケースを構築し、利用可能な資産の範囲を拡大し、取引量の増加をサポートすることであった。その結果、流動性プロバイダーの手数料が上昇し、エコシステムの取引活動が活発化し、取引活動と流動性の増加がエコシステム全体を強化するというフライホイール効果が生まれる。

最大限の透明性

多くのポイントシステムは報酬計算について不透明かもしれませんが、カイア・ポータル・ミッションはキャンペーン期間からポイント計算式まで、最大限の透明性を保つように設計されています。カイアのユーザーにはそれ以上の価値はありません。

キャンペーン期間

このミッションは9月26日に正式に開始され、その後3ヶ月間続いた。この間、各エポックごとに、追加の空輸機会、新たな参加プロジェクト、アセット・ブーストが導入された。

アーリー・アダプター

8月29日から9月26日の間にミッションに参加した場合、ミッションタブに記載されているDeFiプロトコルに1ドル入金するだけでも、対応するウォレットはアーリーアダプターブーストの対象となり、それ以降に獲得したすべてのポイントに1.2倍のボーナス倍率が加算された。

報酬

カイア・リワード

マイルストーンに基づき、最大2,000万KAIAが一般参加者に授与されました。既存のFinschiaエコシステムでFGP-23投票に参加したウォレットは、最大3,000万KAIAを受け取りました。この報酬プールは一般参加者のプールとは別で、FGP-23で投票したウォレット専用です。Finschiaエコシステムで長期にわたってオンチェーンに貢献したユーザーは、Kaiaポータルミッションに参加することで、その貢献度に応じて1,000万KAIAの加重報酬を受け取ります。

25M KAIA（一般参加者1,000万円／FGP-23参加者1,500万円）をポイント・エアドロップに充当。
1,250 万 KAIA（一般参加者は 500 万 KAIA 追加／FGP-23 参加者は 750 万 KAIA） 1 億ドル TVL でロック解除
12.5百万KAIA（一般参加者に5百万KAIA追加／FGP-23参加者に7.5百万KAIA） 150百万TVLでロック解除

FGP-23の参加者プールは、一般の参加者プールと重複しない。

権利確定

キャンペーン終了時に変換されたトークンは、6ヶ月にわたって配布された。キャンペーンが終了し、ユーザーがポイント交換を申請すると、カイアトークンは6ヶ月間の権利確定期間を持つ。

パートナー・プロジェクト報酬

すべての参加者は、それぞれのポータル・ミッションにおいて、各パートナーからポイントを受け取りました。ポイント提供の基準はパートナーによって異なります。カイア・ポータル・ミッションに参加するプロジェクトは、安心して参加できることを保証するために、専門の監査人による監査と検証されたプロトコルを受けることが義務付けられています。

報酬分配

エポック＃1の報酬は、1月7日から6月7日までの6回に分けて分配され、毎月7日に支払われる。分配の内訳は以下の通り：

分割払い1～4：各15
分割払い5～6：各20

参加者はいつでも報酬を請求することができ、最終請求期間は2025年6月30日までとなる。毎月の請求に不便を感じる人は、第6回分割払いが配布された後、一度にすべての報酬を請求することができる。

既存のFNSA長期ステーカーについては、「KAIAオンチェーン・コントリビューター・リワード・ガイドライン」に基づき割り当てられた1,000万KAIAが、ポイント報酬と合算されて分配される。

エポック2が近づくにつれ、カイアのエコシステムにおける新たな発展と強化への期待が高まっています。すでに強固な基盤が整っているため、この次のフェーズでは、機能の向上、機会の拡大、参加者への報酬の増加が期待され、DeFi空間におけるカイアの地位はさらに強固なものとなるでしょう。

KakaoPay、LINE、Telegramのミニアプリのようなプラットフォームとの接続は、DeFiを日常的なユーザーにとってより身近なものにすることで、大衆的な普及を促進するだろう。
分散型取引所（DEX）との継続的な連携により、流動性と取引効率が向上し、スワップがより迅速かつシームレスになる。また、デリバティブや先進的な投資ツールの導入により、機関投資家が集まり、取引機会が拡大する。

カイア・ポータルの探索

カイア・ポータルの例を使ってその方法を見てみよう。👉🏿 https://portal.kaia.io/

例えば、Capybara DEXのStargate Poolに流動性を提供したい場合、Stargateブリッジに基づいて資産を持ち込む必要があります。

イーサリアムからUSDT（スターゲイト）アセットを導入する。

注意してください：逆に、USDT（ETHからのポータル）のようなアセットをステーブルプールに持ち込む場合は、イーサリアムからUSDTを持ち込むためにワームホールブリッジを使用する必要があります。

ブリッジ」タブに行き、スターゲイト・ブリッジを選択する。

スターゲイトブリッジのウェブページでは、あなたの財布を接続し、それがイーサリアムであることを確認し、USDTを持参したいからチェーンを選択します。

受信チェーンとしてカイアを選択する。

Transfer`をクリックし、ウォレットでトランザクションを承認してUSDTをStargateで使用できるようにします。その後、イーサリアムからカイアへの送金が行われます。

LayerZero Scan.👉🏿。https://layerzeroscan.com/

あなたのウォレットにUSDT (Stargate)が表示されていない場合は、「Import Token」をクリックしてUSDT (Stargate)のトークンアドレスを登録してください。 https://portal-docs.kaia.io/english/portal-mission-token-list

USDTがお客様のウォレットに正しく登録されていることをご確認ください。
ポータルブリッジは上記の手順と同様に機能し、このリンクから他のチェーンからカイアにトークンを送ることができる。👉🏿 https://portalbridge.com

ブリッジング・プロセスが完了したので、次は他のポータル機能を探ってみよう。これには、アセットのスワップのデモンストレーションと、BinanceからあなたのウォレットにKAIAを送る方法が含まれます。

スワッピング

スワッピングとは、ある暗号通貨を別の暗号通貨と交換するプロセスを指す。主に分散型取引所で行われる。これらのプラットフォームは仲介者を介さずに運営されており、ユーザー同士が暗号通貨を直接取引できる。

FNSAからカイアへのスワップを見てみよう。

ポータル内の「FNSA -> KAIA」タブは、FNSAトークンからKAIAトークンへのシームレスな変換を容易にします。History（履歴）」タブで変換状況をリアルタイムでモニターすることができます。

9月12日、FGP-23の投票者に4,000万KAIAが配布された。注意点として、ポイントミッションで使用する予定のKAIAウォレットをリンクする必要があります。一度リンクすると元に戻すことはできませんので、今後使用する予定のKAIAウォレットをリンクすることを強くお勧めします。エポック2の仕組みを理解する必要があります。

下の画像のような「請求」ページが表示され、事前にリンクしたKAIAウォレットで報酬を請求することができます。

BinanceからあなたのウォレットへKAIAを送金する

Binanceはご存知の通りグローバルな取引所であり、一度Binanceのウォレットを持っていれば、KAIAを個人のウォレットに引き出すために新しいウォレットを登録する必要はありません。注意すべき点は、Kaia Wallet、Klip、さらにはMetamaskなどのウォレットに引き出すことができるということです。

次のステップでは、引き出し方法について説明します。

まずはBinanceアプリにアクセスし、下部にある「資産」タブを選択します。スポット」セクションで「Kaia」または「Search Kaia」を選択する。

出金」ボタンをクリックし、出金オプションとして「暗号ネットワーク経由で送信」を選択します。

アドレス欄に、個人用ウォレット（カイアウォレット、メタマスク等）のKAIAアドレスを貼り付けます。出金額を設定後、「出金」ボタンをクリックし、「確認」ボタンをクリックすると出金完了です。

取引所の審査プロセスによっては、出金に最大30分かかる場合があります。出金がスムーズに行われない場合は、取引所のカスタマーサポートまでお問い合わせください。

Binanceから個人のウォレットにKAIAを送金する方法を見てきました。

高APRとインセンティブ戦略

カイア・ポータルで収益を高め、最高の年率を得たいですか？トークンを最大限に活用するための主な戦略は以下の通りです。

すべての流動性プールが同じように作られているわけではなく、取引量と需要に基づいてより高い報酬を提供するものもあるため、高利回りのプールを選択する。リターン構造が変わる可能性があるため、リターンが最も良い場所をリサーチして賭け、APRレートや新機能に関する情報を常に入手する方が良いでしょう。
カイアはボーナスイベントや特別プロモーションを頻繁に開催しており、特別報酬を提供しています。期間限定のステーキングブーストや流動性インセンティブにご注目ください。
すべてのKAIAを一つのバスケットに入れないでください！複数のプールやバリデーターに分散投資することで、潜在的なリターンを最大化しつつ、リスクのバランスを取ることができます。
ステークされたKAIAはあなたに議決権を与え、それを使ってエコシステムの形成に役立つガバナンスに参加し、より良い報酬と長期的な成長につなげることができます。

また、助成金や報奨金を通じて、カイアのエコシステムの一部になるための興味深い方法を模索することもできます。

Grants and Bounties

カイアの普及と発展を推進するプロジェクトを構築することができます。以下のガイドラインを使用して始めることができます。

プロジェクトの可能性を見極める
詳細な提案書の作成
プロジェクトを提出する
地域社会との関わり

助成金の種類

カイア・エコシステム・ファンド（KEF）

KEFはカイアのエコシステムサービスと開発者コミュニティの育成に専念しています。KEFから引き出すことを目的としたすべての提案は、最大限の透明性のためにオンチェーン投票によるカイアガバナンス評議会の承認を必要とします。

カイア・インフラストラクチャー・ファンド（KIF）

KIFは、新しいGCの成長を支援し、主要なサービスを開発し、財団の運営を管理するために割り当てられる。基金は自律的かつ透明性をもって運営され、エコシステムの発展に向けた資源の効果的な投入を保証する。

IOK

IOKプログラムは、dApp開発者に技術面、ビジネス面にわたる実用的な市場参入サポートを提供することで、シームレスなビルダーオンボーディングに貢献することを目的としています。世界トップクラスの10以上のカテゴリーに150以上のパートナーが参加しています。このプログラムには、開発者向けとパートナー向けの2つの特典があります。

開発者向け

時間とコストの節約： Kaiaを使用して作成されたDAppsは、プログラムを通じて信頼できるパートナーを見つけることで、時間とコストを節約することができます。
製品開発に集中： Kaiaを使用して作成されたDAppsは、プログラムを通じて信頼できるパートナーを見つけることで、時間とコストを節約することができます。
ネットワーキングの機会：デベロッパーは、時間をかけて優れたリファレンスを蓄積し、業界での評判を高めることができます。
高品質なサービス DAppsは業界をリードする高品質なサービスをリーズナブルな価格で受けることができます。

パートナーの皆様へ

リファレンスの構築：パートナーは、時間をかけて優れたリファレンスを蓄積し、業界での評判を高めることができる。
顧客の獲得と維持パートナーは一貫して顧客を惹きつけ、維持することができる。
ネットワーキングの機会パートナーは、一流プレーヤーとのネットワーキングの機会も利用できる。
初期のコミュニケーション：パートナーは、カイアチェーンにオンボーディングしている多くのdAppsと最初のコミュニケーションの機会を持つ。

D2l

D2I(Dragon DeFi Initiative)プログラムは、カイアの強力なDeFiエコシステムを育成するためのインセンティブプログラムです。現在のD2Iプログラムは、分散型取引所（DEX）やレンディングプロトコルなど、DeFiエコシステムの中核となる公共インフラの発見とサポートを優先しています。つまり、オンチェーンオーダーブックやハイブリッドDEXなど革新的な構造を採用するDAppsや、D2Iの要件を満たす既存のエコシステム参加者もプログラムの対象となる。

報奨金プログラム

チームとカイアのエコシステムから広く認知され、バグの重大性と影響力に基づいて報酬を得ることができます。

報奨金の種類

バグ報奨金

開発者は、プロトコルのバグや脆弱性を見つけることで、最高2万ドルを得ることができる。👉🏿。https://github.com/kaiachain/kaia-dapp-mono/tree/main/bug-bounty

開発報奨金

開発者は、カイアのエコシステムを強化するツール、アプリケーション、リソースを作成することで、最高10万ドルを得ることができます。👉🏿。https://dorahacks.io/org/kaiachain

結論

結論として、カイアはアジアの新しいWeb3世界へのゲートウェイとして有望なビジョンを提示している。その革新的なテクノロジーを探求し、ユーザーフレンドリーなカイア・ポータルを利用し、インセンティブ付きのエコシステムに参加することで、ユーザーはこのエキサイティングなプロジェクトの成長に積極的に貢献することができる。

最新のアップデートやコミュニティへの参加については、以下のリンクからカイアをフォローし、つながってください。

X: 👉🏿 https://x.com/kaiachain?lang=en
Telegram: 👉🏿 https://t.me/KaiaChain_EN
Discord: 👉🏿 https://discord.com/invite/kaia
カイアウェブサイト: https://www.kaia.io/
カイア・ポータル: https://portal.kaia.io/

Mina Meme Series & Telegram Stickers

Adetayo Lasisi — Sat, 15 Feb 2025 22:35:32 +0000

Hey there! Sometimes, you just need to sit back and relax. Before diving into the next meme in the series, why not grab some Mina Telegram stickers and join the community fun? Download them here!

Come to think about it what chains are lighter than Mina

You know it just stays the same

You already know Mina just gets better with its recursive zero-knowledge proofs

Wondering what verifying on Mina looks like

When put against other chains how does it fare

Remember to pick up your copy of the Mina protocol stickers on telegram via this link

You can visit the Mina website
Follow Mina on X(Twitter)
Join the Telegram 👉🏿here
Join the Discord Community 👉🏿here

Kaia: Powering Asia On-Chain Future

Adetayo Lasisi — Wed, 12 Feb 2025 21:14:29 +0000

In this article we will delve into the world of Kaia: its underlying technology, the user-friendly Kaia Portal, and the incentives designed to encourage user participation and ecosystem growth within the Kaia chain.

To read the Japanese version, simply visit here

Introduction

Kaia is a highly optimized BFT-based public blockchain that meets enterprise-grade reliability and performance standards. It powers Asia's on-chain future and was formed through the merger of the Klaytn and Finschia blockchains, which were initially developed by Kakao and LINE, respectively. Kaia brings Web3 to the fingertips of hundreds of millions across Asia.

What is a BFT-based public blockchain

This is a blockchain that utilizes Byzantine Fault Tolerance (BFT). This ensures consensus can be reached even if some nodes fail or act maliciously. The system relies on algorithms designed to handle up to ⅓ of nodes behaving incorrectly or dishonestly, without compromising the integrity of the network. They are more secure and perform better than permissionless blockchains.

BFT is critical for public blockchains because it helps prevent corruption and keeps networks safe and reliable. Without BFT, network participants could introduce false information.

Features and Aim of Kaia

Kaia blockchain offers:

1-second block generation and confirmation time.
Processing capability of 4,000 transactions per second.
Low gas price, approximately 1/10 of Ethereum.
EVM (Ethereum Virtual Machine) compatibility, supporting Solidity contracts.
Governance by reputable corporations worldwide forming Kaia Governance Council.

Kaia blockchain aims to:

Achieve immediate finality for transactions.
Provide high transaction processing speed for real-world use cases.
Lower the cost of running blockchain applications.
Reduce barriers to entry for end-users.
Facilitate easy technology adoption for various industries.

The Kaia Ecosystem

The Kaia ecosystem is built to make decentralized finance (DeFi) simple, accessible, and secure maintaining compliance with regulations. Whether you're staking tokens, trading crypto, or moving assets across different blockchains, Kaia offers a seamless experience. The core components of the ecosystem are:

Kaia Portal: The Kaia Portal is the main hub where users can stake, swap, and earn rewards all in one place. It’s designed to be intuitive, so whether you’re new to DeFi or a seasoned pro, you’ll find it easy to navigate. The goal is to make financial tools easy to use and accessible to everyone.
Staking: Staking KAIA tokens isn’t just about earning rewards, it lets you earn while strengthening the network and also helps keep the blockchain secure. Locking up your KAIA tokens supports validators, secures the network, earns you staking rewards based on the amount and duration of your stake, and gives you a say in governance and a way of providing passive income.
Bridging: One of Kaia’s standout features is its cross-chain bridge, which lets users transfer assets between different blockchains. Bridging refers to the process of transferring assets like cryptocurrencies or NFTs and data between different blockchain networks. Think of it like this: imagine you have money in a bank account in one country and want to use it in another. Bridging is a secure and efficient way to transfer money across borders. Kaia interoperability means users aren’t limited to just one blockchain, they can tap into opportunities across the entire DeFi space.
Decentralized Exchanges (DEXs): Kaia integrates decentralized exchanges like DragonSwap and Kaiaswap, where you can trade cryptocurrencies directly from your wallet—no need for banks or third parties trading without middlemen.

DragonSwap: This is a high-speed DEX with deep liquidity pools.

Kaiaswap: This is a low-fee trading platform optimized for efficiency.

These platforms give users full control of their assets while making trading fast and secure with reduced fees.

These platforms give users full control of their assets while making trading fast, secure, and cost-effective.

Let's dive into the Kaia Portal and discover its exciting features

Kaia Portal

At Kaia, the top priority is delivering seamless Web3 user experiences, ranging from DeFi to on-chain gaming and NFTs. User experience is strongly believed to be essential for making the benefits of Web3 available to everyone, not just those well-versed in crypto. In addition to developing a fast and highly usable Layer 1 blockchain, Kaia has pioneered a messenger wallet that eliminates the need for key management.

Kaia Portal's user-friendly interface on desktop, mobile, and, soon, within LINE Messenger allows you to swap, bridge, stake, and on-ramp easily. In addition to common DeFi functions, a points-based rewards system will soon be added, where old and new users will be rewarded for participating in Missions across the Kaia DeFi and broader ecosystem.

In Epoch 1 of Kaia Portal’s Missions, attractive token reward opportunities were distributed by utilizing Kaia their DeFi partners.

In the subsequent Epoch 2, users who participate in missions involving the Kaia Wave program will receive attractive rewards.

We still have other ways Kaia incentivises their users, including builders, developers and partners, making the ecosystem the place to be.

Kaia Portal Mission Epoch #1 Incentive Design

Although the Epoch #1 missions concluded on December 25, 2024, at 3:00 PM (UTC+9), we want to provide an overview of what occurred and what to look forward to in Epoch #2. It was designed to boost liquidity and user engagement within the Kaia ecosystem. Up to 50 million KAIA tokens were allocated, alongside participating projects. After successfully completing the missions, participants earned points that can be converted into vested KAIA tokens and project tokens once the Epoch ends.

In Epoch 1, the missions revolved around providing liquidity to Kaia DeFi protocols, and the rewards were:

Kaia points
Points from participating projects
D2I program rewards
Yield from DeFi protocols

The goal was to build new applications and DeFi use cases on Kaia, expanding the range of available assets and supporting increased volume. This would result in higher fees for liquidity providers and boost ecosystem trading activity, creating a flywheel effect in which increased activity and liquidity enhance the overall ecosystem.

Maximum Transparency

While many point systems may be opaque about their reward calculations, Kaia Portal Missions are designed to be maximally transparent, from campaign duration to point calculation formulas. Kaia users deserve nothing less.

Campaign Duration

The missions officially began on September 26th and went on for the following three months. During this period, additional airdrop opportunities, new participating projects, and asset boosts were introduced with each Epoch.

Early Adopters

For participants in the missions between August 29th and September 26th, even with a deposit of just $1 into any DeFi protocol listed in the Mission tab, the corresponding wallet qualified for the Early Adopter boost which added a 1.2x bonus multiplier to all points earned thereafter.

Rewards

Kaia Rewards

Up to 20 million, KAIA was awarded to general participants based on milestones. Wallets that participated in the FGP-23 voting in the existing Finschia ecosystem received up to 30 million KAIA. This reward pool is separate from the general participants’ pool and is exclusively for wallets that voted in FGP-23. Users with long-term on-chain contributions in the Finschia ecosystem receive a weighted reward of 10 million KAIA by participating in the Kaia Portal Missions, based on their contributions.

25M KAIA (10M for general participants / 15M for FGP-23 participants) allocated for the points airdrop
12.5M KAIA (5M additional KAIA for general participants / 7.5M KAIA for FGP-23 participants) unlocked at $100M TVL
12.5M KAIA (5M additional KAIA for general participants / 7.5M KAIA for FGP-23 participants) unlocked at $150M TVL

The pool for FGP-23 participants does not overlap with the general participant pool.

Vesting

Tokens converted at the end of the campaign were distributed over six months. When the campaign ends and a user claims point conversion the Kaia Tokens will have a 6-month vesting period.

Partner Project Rewards

All participants received points from each partner in their respective Portal Mission, the criteria for points provision vary by partner. Participating projects in Kaia Portal Missions are required to have been audited by professional auditors and verified protocols, to guarantee safe participation with confidence.

Reward Distribution

The rewards for Epoch #1 are distributed over six instalments from January 7 to June 7, with payments made on the 7th of each month. The distribution breakdown is as follows:

Installments 1–4: 15% each
Installments 5–6: 20% each

Participants can claim their rewards anytime, with the final claim period ending on June 30, 2025. For those who find monthly claims inconvenient, they can claim all rewards in one go after the sixth instalments have been distributed.

For existing FNSA long-term stakers, the 10 million KAIA allocated under the “KAIA On-chain Contributor Rewards Guidelines” will be combined with the point rewards for distribution.

As Epoch 2 approaches, anticipation is building for new developments and enhancements within the Kaia ecosystem. With a strong foundation already in place, this next phase is expected to bring improved features, expanded opportunities, and greater rewards for participants, further solidifying Kaia’s position in the DeFi space.

Connecting with platforms like KakaoPay, LINE, and Telegram mini-apps will drive mass adoption by making DeFi more accessible to everyday users.
Ongoing collaborations with decentralized exchanges (DEXs) will improve liquidity and trading efficiency, making swaps faster and more seamless and the introduction of derivatives and advanced investment tools will attract institutional investors and expand trading opportunities

Exploring the Kaia Portal

The Kaia portal also lets us do the following: sending KAIA from Binance to your wallet, bridging from another chain to Kaia, depositing into a DeFi Pool and earning points (Point Farming Tip: FNSA > KAIA Swap).

Bridging on the Kaia portal

Let's see how it's done using a Kaia Portal example, go to this link to access the portal 👉🏿 here

We start with checking which DEX Pool you want to provide liquidity for in Mission, For instance, if you want to provide liquidity to the Stargate Pool on Capybara DEX, you need to bring in assets based on the Stargate bridge

We’ll bring in USDT (Stargate) assets from Ethereum.

Note that: Conversely, if you want to bring assets like USDT (portal from ETH) for the Stable Pool, you will need to use the Wormhole bridge to bring USDT from Ethereum.

Go to the “Bridge” tab and select the Stargate bridge.

On the Stargate bridge webpage, connect your wallet and select the chain from which you want to bring USDT ensure it's Ethereum

You select Kaia as the receiving chain.

Click Transfer, then approve the transaction in your wallet to allow USDT to be used on Stargate. After that, the transfer from Ethereum to Kaia will proceed.

You can always check the transfer status on LayerZero Scan.👉🏿 here

If you don’t see the USDT (Stargate) listed in your wallet, click “Import Token” and register the USDT (Stargate) token address You can find the token addresses via the provided link 👉🏿 here

Ensure that USDT is properly registered in your wallet.
The Portal bridge functions similarly to the above steps, and you can send tokens from other chains to Kaia through this link 👉🏿 here

With the bridging process complete, let's now explore other portal features. This will include a demonstration of swapping assets and how to send KAIA from Binance to your wallet.

Swapping

Swapping refers to the process of exchanging one cryptocurrency for another. It primarily occurs on decentralized exchanges. These platforms operate without intermediaries, allowing users to directly trade cryptocurrencies with each other.

Let's see how we can swap from FNSA to Kaia

The FNSA -> KAIA tab within the Portal facilitates the seamless conversion of FNSA tokens to KAIA tokens, with the conversion process typically taking over 30 minutes to ensure maximum security. You can conveniently monitor the conversion status in real-time through the 'History' tab.

For those who claimed rewards, the 40 million KAIA reward for FGP-23 voters was distributed on September 12th. It is important to note that you must link the KAIA wallet that you intend to use for the points mission. Once linked, this process cannot be undone, so we highly recommend that you link the KAIA wallet you plan to use going forward. It is necessary to understand how this works for Epoch 2

The Claim page, as shown in the image below, will become available, allowing you to claim your rewards with your previously linked KAIA wallet.

Sending KAIA from Binance to your wallet

Binance as we know it is a global exchange, once you have a Binance wallet there's no need to register a new wallet to withdraw KAIA to a personal wallet. Something to note is you can withdraw to wallets such as Kaia Wallet, Klip, and even Metamask.

The next couple of steps will guide you on how to withdraw

Start by accessing the Binance app and selecting the Assets tab at the bottom. In the Spot section choose Kaia or Search Kaia

Click the Withdraw button then select the Send via Crypto Network as the withdrawal option

In the Address field, paste the KAIA address of your personal wallet (Kaia Wallet, Metamask, etc.). After setting the withdrawal amount, click the “Withdraw” button and then click “Confirm” to complete the withdrawal request.

Withdrawals may take up to 30 minutes depending on the exchange’s review process. If the withdrawal is not processed smoothly, please contact the exchange’s customer support for assistance.

We have seen a way to send KAIA from Binance to your personal wallet, what If we want to bridge from one chain to Kaia

You can also deposit into a DeFi Pool and earn points in the following ways

Deposit to Capybara 👉🏿 here
Deposit to Dragonswap 👉🏿 here
Deposit to Kaiaswap 👉🏿 here

Strategies for High APR and Incentives

Want to boost your earnings and get the best Annual Percentage Rates on the Kaia Portal? Here are some key strategies to help you make the most of your tokens

Choosing high-yield pools because not all liquidity pools are created equal and some offer higher rewards based on trading volume and demand. It is better to research and stake where the returns are the best and stay informed on APR rates, and new features, as reward structures can change.
Simply participating in promotions since Kaia often runs bonus events and special promotions that offer extra rewards. Stay on the lookout for limited-time staking boosts and liquidity incentives.
Don’t put all your KAIA in one basket! Spreading your stake across multiple pools or validators helps balance risk while maximizing potential returns.
Your staked KAIA gives you voting power, use it to participate in governance that helps shape the ecosystem, which can lead to better rewards and long-term growth

We can also explore interesting ways to be part of the Kaia ecosystem through Grants and Bounties

Grants and Bounties

You can build projects that drive the adoption and advancement of Kaia. You can begin using the Guidelines below

Identify the potential of your projects
Prepare a detailed proposal
Submit your project
Engage with the community

Types of Grant

Kaia Ecosystem Fund (KEF)

The KEF is dedicated to fostering Kaia ecosystem services and developer communities. All proposals aiming to draw from the KEF will require approval from the Kaia Governance Council via on-chain voting for maximum transparency.

Kaia Infrastructure Fund (KIF)

The KIF is allocated to support the growth of new GCs, develop key services, and manage foundation operations. The fund operates autonomously and transparently, ensuring that resources are effectively directed towards the ecosystem’s development.

IOK

The IOK program is designed to contribute towards seamless builder onboarding by providing pragmatic, go-to-market support across the technical, and business aspects for dApp developers. With over 150+ partners across 10+ categories among global top-tier players. This program has two classifications to benefit from, one for developers and one for partners

For Developers

Time and Cost Savings: DApps created using Kaia can save time and costs by finding reliable partners through the program.
Focus on product development: DApps created using Kaia can save time and costs by finding reliable partners through the program.
Networking Opportunities: Developers can accumulate excellent references over time, enhancing their reputation in the industry.
Quality services: DApps can receive industry-leading quality services at reasonable prices.

For Partners

Building references: Partners can accumulate excellent references over time, enhancing their reputation in the industry.
Attracting and retaining customers: Partners can consistently attract and retain customers.
Networking Opportunities: Partners can also take advantage of networking opportunities with top-tier players.
Early Communication: Partners have the first communication opportunity with a number of dApps that are onboarding to the Kaia Chain.

D2l(Dragon DeFi Initiative)

The D2I(Dragon DeFi Initiative) program is an incentive program to foster a strong DeFi ecosystem on Kaia. The current D2I program prioritizes the discovery and support of public infrastructure, such as decentralized exchanges (DEXs) and lending protocols, which are core to any DeFi ecosystem. This means DApps that adopt innovative structures, such as on-chain order books and hybrid DEXs, as well as existing ecosystem participants that meet the requirements of D2I are also eligible for the program.

Bounty Program

You can get widespread recognition from the team and Kaia ecosystem and earn rewards based on the severity and impact of the bugs and build a track record to explore more opportunities with Kaia projects

Type of Bounties

Bug Bounties
Developers can earn up to $20K by finding protocol bugs and vulnerabilities. To get started just simply visit 👉🏿here

Dev Bounties
Developers can earn up to $100K by creating tools, applications, and resources that enhance the Kaia ecosystem. To get started just simply visit 👉🏿here

Conclusion

In conclusion, Kaia presents a promising vision for a gateway to the brave new Web3 world in Asia. By exploring its innovative technology, utilizing the user-friendly Kaia Portal, and participating in the incentivized ecosystem, users can actively contribute to the growth of this exciting project.

For the latest updates and community engagement, follow and connect with Kaia on the following links

X: 👉🏿 here
Telegram: 👉🏿 here
Discord: 👉🏿 here
Visit the official Kaia website and Portal to learn more and get involved.

Building On Mina: A guide to writing smart contract implementing Merkle Trees using 01js

Adetayo Lasisi — Sat, 01 Feb 2025 20:15:09 +0000

This article will explore Merkle Trees within the Mina ecosystem, demonstrating their practical application with a step-by-step creation of a Voting Zk App.

Introduction

A blockchain consists of a chain of blocks, with each block containing one or more transactions. Each block is identified by a cryptographic hash representing its contents, including transactions and metadata.

Within a block, transactions are structured using a Merkle tree, where each transaction is represented by a hash. These transaction hashes serve as the leaves of the tree. Each pair of transaction hashes is recursively hashed together until a single root hash, called the Merkle root, is obtained. This Merkle root, along with other block metadata, is then included in the block header, ensuring data integrity and efficient verification.

In Mina, zkApp accounts can only store a limited amount of data to prevent bloating. Hence, need for a Merkle tree, which allows the referencing of off-chain data by storing only a single hash on-chain, thereby enabling Mina to maintain its succinctness.

The Merkle tree root summarizes and verifies the integrity of a set of data and is used to prove that some data exists in the Merkle tree, the root is considered a compact representation of a large pool of data so this allows an efficient verification and confirmation of data integrity inside the blockchain system.

Another benefit of Merkle trees is the witness, also known as a Merkle proof or Merkle path. The witness is the path from one specific leaf node to the very top of the tree which is the root. Merkle witnesses are proofs of inclusion that prove that one specific piece of data

You can reference large amounts of off-chain data and prove the inclusion of very specific parts of that data with only a small hash - the root - and a witness.

Let's start building.

Imagine we have a zkApp where users can vote for their favourite NFTs. Each vote increases the NFT’s count, and once an NFT reaches a certain number of votes, it can claim a reward. But storing all this data on-chain isn’t practical with so many NFTs and voters—it would quickly run out of space.

We make use Merkle trees to keep NFT vote data off-chain while still allowing the smart contract to verify and update votes securely.

We'll take the first step by installing the zkapp-cli.

npm install -g zkapp-cli

After we have that installed we'll enter this command to create a project

zk project votingNft

We'll have the choice to select one of the options in the image below, navigate the options and select none

After that has been selected, the project will be created, after it's done we will navigate to the folder from the terminal using

cd votingNft

We need to remove some files that have been generated along with the project because we won't be using them. With this command, we'll delete the files

cd src
rm Add.test.ts Add.ts interact.ts

Then while still in the src directory, we run this command to create the necessary files we exit the src directory

touch Voting.ts Voting.test.ts

//exit the directory
cd ..

Navigate to index.ts and replace the content with

import { Voting } from './Voting.js';

export { Voting };

We are ready to start building so let's open the Voting.ts file, we import the necessary packages that we need to get this ball rolling

import { Field, SmartContract, state, State, method, Struct, MerkleWitness, Poseidon, Provable } from "o1js";

We need to define a tree height, The tree height decides how many layers of grouping are needed, affecting how quickly and easily data can be verified and we'll create a corresponding Merkel Witness class

The height states how many leaves we can have when specifying the witness, we'll see this in action when taking a look at the data in the tree

export const treeHeight = 4

export class MerkleWitness4 extends MerkleWitness(treeHeight){}

Now let's create our main Voting smart contract and initialize it

export class Voting extends SmartContract{
    // declare state variables
    @state(Field) voters = State<Field>()
    @state(Field) winningNft = State<Field>()
    @state(Field) winningVotes = State<Field>()

    // root of the merkle tree
    @state(Field) treeRoot = State<Field>()

    init(){
      super.init()
      this.voters.set(Field(1))
    }

   // initialize the state on the contract
       @method async initState(initialRoot: Field){
     this.treeRoot.set(initialRoot)
   }
}

We define the state variables to hold the voters, winningNft, winningVotes and the treeRoot, and then we initialize the state of the contract. We continue by creating a Class for the NFT and create a method to vote.

export class NFT extends Struct({nftName: Field, nftCreator: Field, nftVotes: Field}){

//method for the vote
vote(){
  this.nftVotes = this.nftVotes.add(1)
 }
}

First, we verify that the NFT is present in the Merkle tree. Once confirmed, the voting process takes place. After casting the vote, we check if the currently voted-on NFT has surpassed the current winner in votes. If it has, we update the winner. Otherwise, the existing winning NFT remains unchanged. Finally, the Merkle tree is updated to reflect any changes made to the NFT. we implement the method voteForNft to handle this entire process.

export class Voting extends SmartContract{
  // declare state variables
  @state(Field) voters = State<Field>()
  @state(Field) winningNft = State<Field>()
  @state(Field) winningVotes = State<Field>()

  // root of the merkle tree
  @state(Field) treeRoot = State<Field>()
     init(){
       super.init()
       this.voters.set(Field(1))
     }

  // initialize the state of the contract
  @method async initState(initialRoot: Field){
    this.treeRoot.set(initialRoot)
   }

 //method to vote for the nft
 @method async voteForNft(nft: NFT, witness: MerkleWitness4){

  //Get the tree root and see if the nft is in it
  const treeRoot = this.treeRoot.getAndRequireEquals()

  // check to see whether the nft is in the merkle tree, the way we check to see if the nft is within the tree is by the witness        

  const nftRoot = witness.calculateRoot(Poseidon.hash(NFT.toFields(nft)))

  // check if the nft is in the tree, if it is not in the tree, the transaction will fail and the state will not be updated

   nftRoot.assertEquals(treeRoot)

  //if the nft is in the tree then the nft can be voted on
  nft.vote()

  //update the tree with the new nft hash
  const newNftRoot = witness.calculateRoot(Poseidon.hash(NFT.toFields(nft))
this.treeRoot.set(newNftRoot)

        this.voters.set(this.voters.getAndRequireEquals().add(1)) //we want to increment the number of voters after a vote has been cast

//we are going to check if the nft has more votes than the current winning nft then we will update the winning nft

  const winningNft = this.winningNft.getAndRequireEquals()
  const winningVotes = this.winningVotes.getAndRequireEquals()

  const newWinningNft = Provable.if(winningVotes.lessThan(nft.nftVotes), nft.nftName, winningNft)
  const newWinningVotes = Provable.if(winningVotes.lessThan(nft.nftVotes), nft.nftVotes, winningVotes)

this.winningNft.set(newWinningNft)
this.winningVotes.set(newWinningVotes)
  }
}

This method verifies, votes, and updates the winning NFT on the Merkle tree.

First, we verify the nft in the tree by retrieving the Merkle root, hashing with Poseidon, and checking if it exists in the tree via a Merkle witness.
We cast the Vote & Update Tree, If it is valid, we call nft.vote(), and update the Merkle root, setting a new root in this.treeRoot.
We increase the voter count by increasing voters to track the number of participants.
Finally we update the winning NFT, using Provable.if to compare votes, and update winningNft and winningVotes, if the new NFT has more votes.

Poseidon: Poseidon is a hash function for zero knowledge-proof systems, we use it because it only stores field variables but since the nft is a struct we have to pass it as fields

With this, we have our smart contract ready, and now we can test our smart contract.

We'll navigate to our Voting.test.ts file and start adding some code, the first thing we need to do is import the necessary packages and files

import { AccountUpdate, CircuitString, Field, MerkleTree, Mina, Poseidon, PrivateKey, PublicKey } from 'o1js';
import { treeHeight, NFT, MerkleWitness4, Voting } from './Voting';

Then we set up the tests with

let proofsEnabled = false;

function createNFT(nftName: string, nftCreator: string) {
   const nft = new NFT({
        nftName: Poseidon.hash(CircuitString.fromString(nftName).values.map(char => char.toField())),
        nftCreator: Poseidon.hash(CircuitString.fromString(nftCreator).values.map(char => char.toField()),
        nftVotes: Field(0)
    });
    return nft;
}

function createTree(): MerkleTree {
    const tree = new MerkleTree(treeHeight);

    const nft0 = createNFT("nft0", "creator0");
    const nft1 = createNFT("nft1", "creator1");
    const nft2 = createNFT("nft2", "creator2");
    const nft3 = createNFT("nft3", "creator3");

    tree.setLeaf(0n, Poseidon.hash(NFT.toFields(nft0)));
    tree.setLeaf(1n, Poseidon.hash(NFT.toFields(nft1)));
    tree.setLeaf(2n, Poseidon.hash(NFT.toFields(nft2)));
    tree.setLeaf(3n, Poseidon.hash(NFT.toFields(nft3)));

    return tree;
}


describe('Voting', () => {
    let deployerAccount: Mina.TestPublicKey,
    deployerKey: PrivateKey,
    senderAccount: Mina.TestPublicKey,
    senderKey: PrivateKey,
    zkAppAddress: PublicKey,
    zkAppPrivateKey: PrivateKey,
    zkApp: Voting,
    tree: MerkleTree;

    beforeAll(async () => {
        if (proofsEnabled) await Voting.compile();
    });

    beforeEach(async () => {
        const Local = await Mina.LocalBlockchain({ proofsEnabled });
        Mina.setActiveInstance(Local);
        [deployerAccount, senderAccount] = Local.testAccounts;
        deployerKey = deployerAccount.key;
        senderKey = senderAccount.key;

        zkAppPrivateKey = PrivateKey.random();
        zkAppAddress = zkAppPrivateKey.toPublicKey();
        zkApp = new Voting(zkAppAddress);
        tree = createTree();
    });

async function localDeploy() {
        const txn = await Mina.transaction(deployerAccount, async () => {
            AccountUpdate.fundNewAccount(deployerAccount);
            await zkApp.deploy();
            await zkApp.initState(tree.getRoot());
        });
        await txn.prove();
        await txn.sign([deployerKey, zkAppPrivateKey]).send();
    }
})

In this test setup, we use the createTree function to generate a Merkle tree with dummy data for the NFTs that we will vote on.

The proofsEnabled flag controls whether zero-knowledge proofs will be generated. We set it to false during the initial stages of development to speed up the process.

We define the localDeploy function, which is executed before each test suite to deploy the smart contract and initialize its state."

The describe block in the test is used to group the related tests, providing a clear structure for our testing process.

For our first test suite, we will generate and deploy the contract

it('generates and deploys the contract', async () => {
        await localDeploy();
        const treeRoot = zkApp.treeRoot.get();
        expect(treeRoot).toEqual(tree.getRoot());
    });

Our next step is to check if the votes are incremented correctly

 it('votes on the Nft are incremented correctly', async () => {
        await localDeploy();

        const nft1 = createNFT("nft1", "creator1");
        nft1.vote();
        expect(nft1.nftVotes).toEqual(Field(1));
    });

Now, let's test whether the voting process for an NFT works correctly.

it('correctly votes for NFT', async () => {
        await localDeploy();

        const nft1 = createNFT("nft1", "creator1");
        const witness = new MerkleWitness4(tree.getWitness(1n));

        const txn = await Mina.transaction(senderAccount, async () => {
            zkApp.voteForNft(nft1, witness);
        });

        await txn.prove();
        await txn.sign([senderKey]).send();

        const voters = zkApp.voters.get();
        expect(voters).toEqual(Field(1));

        const winningNft = zkApp.winningNft.get();
        expect(winningNft).toEqual(nft1.nftName);

        const winningVotes = zkApp.winningVotes.get();
        expect(winningVotes).toEqual(Field(1));

        nft1.vote();
        tree.setLeaf(1n, Poseidon.hash(NFT.toFields(nft1)));
        const treeRoot = zkApp.treeRoot.get();
        expect(treeRoot).toEqual(tree.getRoot());
    });

We've just verified that the NFT data is present in the tree using the witness, allowing us to correctly cast a vote. Next, we'll test a scenario where we attempt to vote on an NFT not present in the tree, to observe the system's behavior when provided with incorrect data.

it('does not allow voting for song not in the tree', async () => {
        await localDeploy();

        const nft12 = createNFT("nft12", "creator1");
        const witness = new MerkleWitness4(tree.getWitness(1n));

        await expect(async () => {
            const txn = await Mina.transaction(senderAccount, async () => {
                zkApp.voteForNft(nft12, witness);
            });

            await txn.prove();
            await txn.sign([senderKey]).send();
        }).rejects.toThrow();
    });

In the final test suite, we'll cast votes for multiple NFTs, including voting for one twice, to determine the winner.

it('correctly votes for two songs and chooses the right winner', async () => {
        await localDeploy();
        const nft1 = createNFT("nft1", "creator1");
        const nft2 = createNFT("nft2", "creator2");

        let witness = new MerkleWitness4(tree.getWitness(0n));
        let txn = await Mina.transaction(senderAccount, async () => {
            zkApp.voteForNft(nft1, witness);
        });
        await txn.prove();
        await txn.sign([senderKey]).send();
        nft1.vote();
        tree.setLeaf(0n, Poseidon.hash(NFT.toFields(nft1)));

        let witness2 = new MerkleWitness4(tree.getWitness(1n));
        txn = await Mina.transaction(senderAccount, async () => {
            zkApp.voteForNft(nft2, witness2);
        });
        await txn.prove();
        await txn.sign([senderKey]).send();
        nft2.vote();
        tree.setLeaf(1n, Poseidon.hash(NFT.toFields(nft2)));

        witness = new MerkleWitness4(tree.getWitness(0n));
        txn = await Mina.transaction(senderAccount, async () => {
            zkApp.voteForNft(nft1, witness);
        });
        await txn.prove();
        await txn.sign([senderKey]).send();
        nft1.vote();
        tree.setLeaf(0n, Poseidon.hash(NFT.toFields(nft1)));

        const voters = zkApp.voters.get();
        expect(voters).toEqual(Field(3));

        const winningSong = zkApp.winningNft.get();
        expect(winningSong).toEqual(nft1.nftName);

        const winningVotes = zkApp.winningVotes.get();
        expect(winningVotes).toEqual(Field(3));

        const treeRoot = zkApp.treeRoot.get();
        expect(treeRoot).toEqual(tree.getRoot());
    });

This finalizes our test, after this is done we run the tests using any of these commands

//run all tests

npm run test

//run in watch mode

npm run testw

After running our tests, we can deploy our smart contract.

To deploy we first have to config the zkApp, we will go to our terminal and run this command

zk config

It asks the following questions to configure your zkApp

Create a name: Enter any desired name for your application.
Choose the target network: Select testnet for testing purposes.
Set the Mina GraphQL API URL to deploy to: Use https://api.minascan.io/node/devnet/v1/graphql
Set transaction fee to use when deploying: Set the fee to 1

Choose an account to pay transaction fee: Choose Create a new fee payer key pair.
Create an alias for this account: Assign a name to the feepayer account (this can be anything).

This is what we get after all the necessary fields are filled

Ensure to fund your account with the provided faucet link, when you open the link you should have something like this. It is necessary to fund your account to ensure the deployment is successful

After we have this completed, we run the command zk deploy voting

zk deploy voting

A single question will be asked to confirm the deployment transaction and we just have to enter yes, and we will have feedback that looks like this which also holds the deployment link

Conclusion

By leveraging Merkle trees, zkApps can handle large-scale data efficiently while keeping Mina’s blockchain lightweight and succinctness, keeping data off-chain while still allowing secure verification.

Beyond NFT voting, they can be used for private identity verification, membership proofs, leaderboards, and decentralized reputation systems.
With this knowledge, go forth and build amazing applications that are powered by the efficiency of Mina's succinct blockchain.

Mantle Network: The Modular Layer-2 Gem

Adetayo Lasisi — Sat, 25 Jan 2025 11:54:30 +0000

Introduction

Mantle Network is a high-performance Ethereum layer 2 network built with a modular design that ensures low fees and high security. Mantle Network is the first modular layer 2 solution built for hyper-scaled dapps. Execution, data availability and transaction finality are in separate layers which enables increased transaction throughput which reduces the fees and reinforces the security and decentralized nature of Ethereum.

Key Features of Mantle

Built as a Rollup: It leverages Ethereum validators to reduce gas fees, lower latency, and boost throughput, with customizable settings for near real-time transaction confirmations.
Modular Architecture: It operates as a modular chain, separating execution, consensus, settlement, and storage into distinct layers. It features an EVM-compatible execution layer, Ethereum-based consensus and settlement layers, and an external data availability component Mantle DA, transitioning to EigenDA upon its mainnet launch.
Secured by Ethereum: With L2 state transitions verified by Ethereum validators, it undergoes the same consensus and settlement processes as L1 transactions.
Modular Data Availability: It uses independent data availability modules, like Mantle DA powered by EigenDA technology from EigenLayer, offering potential cost savings of over 90% compared to on-chain L1 solutions.

Before diving into the history of Mantle and how it came about, let's define some key concepts that will be discussed throughout this article. This will help those new to the web3 ecosystem better understand the information presented

L1 (Layer 1): The base layer of a blockchain network (like Bitcoin or Ethereum), responsible for core functions like security and consensus.
L2 (Layer 2): A secondary network built on top of an L1 blockchain, designed to improve scalability and reduce transaction costs.
Rollups: An L2 solution that processes transactions off-chain and submits a summarized record back to the L1 for security.
EigenLayer: A protocol that allows Ethereum stakers to "restake" their ETH to secure other protocols and applications built on top of Ethereum
On-chain: Activities or data that occur directly on the blockchain, ensuring transparency, security, and immutability.
Off-chain: Activities or data that happen outside the blockchain, often for efficiency or cost reasons, with the results later reflected on-chain.
ZK proofs: ZK proofs also known as Zero-knowledge are cryptographic methods that allow one party to prove the truth of a statement to another without revealing any additional information beyond the validity of the statement.

Overview and History of Mantle

Mantle was created by BitDAO, a DAO launched by the centralized exchange Bybit to support and empower builders. In February 2023, the Mantle core team proposed a $200 million fund on BitDAO's governance forum to grow the Mantle ecosystem. Half of the funding ($100 million) would come from the BitDAO treasury, with the remaining $100 million from external investors such as Pantera Capital, Spartan, QCP Capital, and Dragonfly. The fund is set to drive ecosystem growth.

In May 2023, a proposal to rebrand Mantle Network and BitDAO under the unified Mantle brand was approved, with 235 million $BIT(now $MNT) votes in favour and only 988 votes against. The goal was to adopt a "one brand, one token" approach, creating a unified ecosystem with a stronger product focus.

As part of the rebrand, the initial rollup component was officially named the Mantle Network, while BitDAO was rebranded as Mantle Governance. Mantle has its native utility token, $MNT, which is used for governance, staking, and paying transaction fees on the network.

The Mantle team includes key figures such as Ben Zhou, CEO and co-founder of Bybit, and Jordi Alexander, Chief Alchemist of Mantle.

Why Mantle Network?

Like all other optimistic L2s, Mantle Network seamlessly integrates with the Ethereum virtual machine allowing transactions to be offloaded from the mainnet, Mantle's uniqueness stems from its modular architecture that combines optimistic rollups with an enhanced data availability solution through EigenLayer which allows it to execute multiple transactions at once, establish efficient communication with the main network, and ensure that the network is not overrun by malicious blocks respectively.

Optimistic rollups group transactions into batches to be submitted to the Ethereum mainnet reducing load and gas fees. The data availability is made possible with EigenDA, the game-changing feature which is the first service built on EigenLayer. This allows Mantle to inherit Ethereum's security while significantly reducing gas fees, making transactions up to 70% cheaper.

Mantle Network's Architecture

Mantle v2 Tectonic processes transactions through a sequence of modules that interact with the EigenDA-supported Mantle Data Availability (DA). Users send signed transactions, which are packed into blocks by the sequencer. The op-batcher encodes and compresses the data, then stores it in the DA module before submitting validity information to the Ethereum L1 contract. Similarly, op-proposers send state root data to the L1 contract. Rollup transaction data is stored on Mantle DA, where verifiers can check its validity.

Mantle v2 Tectonic also introduces a transaction pool for temporary storage of transactions, improving transaction packing. The pool supports EIP-1559, letting users control transaction speed through priority fees. The pool is designed to be private, and transactions are processed based on their base and priority fees. In Mantle v2 Tectonic, $MNT serves as the native token for the system. This aims to provide users with a more flexible and efficient transaction experience, laying a solid foundation for the ecosystem's future development.

Transaction Lifecycle

The Initiation Users and dApps interact with the Mantle Network by connecting to the sequencer node's RPC endpoint. Users typically connect their wallets, while dApps integrate the Mantle SDK. They create requests with the recipient's address and transfer amount, ensuring they have enough balance to cover the required transaction fees. For wallets, calculating the required fee is straightforward, but dApps must perform more detailed fee calculations. After preparing the request, users or dApps sign it with their private keys and send it to Mantle, where the sequencer processes the transaction.
The Handling Once the transaction is received, the Ethereum Virtual Machine (EVM) running on op-geth nodes verifies its validity, checks that fees are paid, and transitions the state accordingly. The op-proposer then submits the new Merkle root to the Ethereum L1 contract. State submission happens after a batch of transactions, rather than after each individual transaction. Pending blocks, containing updated states, wait for further processing. These blocks are combined into batches that are encoded, compressed, and sent to Ethereum for final settlement, reducing transaction costs by sharing fixed fees across multiple transactions.
The Storage Mantle Network uses its own Data Availability (DA) system, Mantle DA, for efficient and cost-effective storage of transaction data. op-batcher submits the encoded transaction data to Mantle DA to ensure the integrity of the network. DA nodes synchronize and make data accessible at all times, earning $MNT rewards for their services. State data is stored securely on Ethereum, where it undergoes validation through Ethereum's consensus mechanism. Once verified, the state root is recorded on Ethereum, and the transition is finalized after the challenge period (usually 7 days).

Onchain System

According to the docs Mantle Network's on-chain module contains a series of smart contracts that run on the blockchain to ensure decentralized and reliable execution. These contracts are responsible for handling the logic of various dApps interacting with the blockchain, as well as the interaction of the off-chain system with the on-chain system, including asset transfers, asset swaps, and so on.

Offchain System

The off-chain System is another key module of the Mantle Network. It is responsible for executing specific tasks and logic in an environment outside of the blockchain, which is key to Layer 2's ability to scale L1 and provide more efficient and faster response and execution.

Tokens in Mantle Network

This introduces us to the world of Mantle's native token, $MNT (formerly known as $BIT), along with mUSD, Mantle's stablecoin, and mShard, a product of the partnership with Ethena.

MNT Token

The MNT token is an ERC-20 token serving as both a governance and utility token within the Mantle ecosystem. It grants holders voting rights for DAO decisions and is also used to pay for gas fees. Additionally, MNT can act as a secondary collateral asset for Ethereum validators powering EigenDA, enhancing the network's security and stability. With a maximum supply of just over 6.2 billion tokens and over 3.3 billion tokens in circulation. In the Mantle v2, MNT has transitioned from an ERC-20-based design to one that uses ETH for gas fees, aligning more closely with Ethereum’s native architecture for seamless integration into its ecosystem.

Mantle v2 is also introducing meta-transactions to facilitate the payment of transaction fees and provide a more flexible and smooth experience. This lets users interact without paying gas fees or waiting for transaction confirmations.

mUSD

The mUSD is an exclusive rebasing-wrapped version of Ondo Finance’s yield-bearing stablecoin, USDy, designed to maintain a consistent $1 peg. Its introduction on the Mantle Network is a collaborative effort between Mantle and Ondo Finance, enabling users to directly access real-world U.S. Treasury yields. Interest is distributed to users via the rebasing mUSD token.

mShard

Mantle partnered with Ethena to introduce USDe, a delta-neutral synthetic dollar that doesn’t rely on traditional banking infrastructure and leverages liquidity from both centralized and decentralized exchanges. This marks Ethena’s first cross-chain deployment and is expected to see wide adoption across Mantle’s Layer 2 applications.

Additionally, the Mantle Rewards Station launched with Ethena’s Shards, offers $MNT holders rewards and perks from popular Mantle ecosystem dApps. As part of the "Mantle Sharding with Ethena" event, mShard holders can redeem Ethena’s native token, $ENA, at a conversion rate of 582 mShards to 1 $ENA.

To participate you can visit here

mETH Protocol formerly Mantle LSP

This is a permissionless, non-custodial ETH liquid staking protocol on Ethereum L1, allowing you to stake your ETH and earn competitive yields. it uses Mantle Staked Ether (mETH) as the value-accumulating receipt token. The goal of mETH is to become the most widely adopted and capital-efficient ETH staking token. To achieve this, it is integrated across multiple Mantle Layer 2 DeFi apps, core tech partners, and centralized exchanges.

The concept for mETH, inspired by Lido's liquid ETH, was proposed by Jordi Alexander. He describes Mantle's liquid staking protocol as a "lighter, more modern version of Lido" and hopes it appeals to users concerned about Lido's centralization.

When asked about the differences, Jordi said:

"The design is more simpler, more modern, we need to look at where Lido came from. They came from a pre-proof-of-stake world, a lot of designs for things like Rocket Pool and Lido, they had to take into consideration this previous world and merge into a complicated difficult design."

Ecosystem

In July 2023, the Mantle Network mainnet launched, providing developers and users access to a full ecosystem of tools and dApps, including the mainnet bridge, explorer, and safe multisig. Also, Mantle introduced its inaugural modular dynamic NFT collection in collaboration with visual artist Chen Man. Titled Citizens of Mantle, the collection allowed around 38,000 users to acquire their own Mantle Companion NFT. To learn more you can visit here

With a substantial treasury to incentivize builders and a transparent system that lets users track treasury activity, Mantle aims to foster innovation and growth within its ecosystem. You can also view the various dapps that have been built using Mantle here

Mantle Missions

Mantle also allows users a earn various exclusive rewards by completing Mantle Ecosystem quests. To learn more you can visit here

Grants

With Mantle's aim is to foster a strong entrepreneur & developer community through its wide range of grant initiatives. Mantle is committed to supporting projects across all stages through Flagship Buildathon Programs & the Mantle Scouts Program.

For teams at the pre-product stage looking for technical and go-to-market support, Mantle encourages them to join the Mantle ecosystem by applying to the Flagship Buildathon Programs. These programs have various categories and geographic focus and happen on a rolling basis throughout the year. Top-performing teams may qualify for additional grants and ecosystem support. For individuals looking to explore this further, they can visit here

Bounties

Mantle also has a bug bounty program that incentivizes security researchers to identify and report vulnerabilities in the LSP protocol. The program is open to all security researchers, regardless of experience or affiliation. Rewards are distributed according to the impact of the vulnerability based on the Immunefi Vulnerability Severity Classification System V2.3.

There are different categories with rewards to follow

Critical: Max is $500,000 and the min: is $100,000.
High: Max is $100,000 and the min: is $20,000.
Medium: where the flat is $5,000.

To interested individuals in this field, you can visit here

ZK Validity Rollup with Succinct’s SP1

Mantle Network is revolutionizing decentralized finance by transitioning to zero-knowledge (ZK) validity rollups through Succinct’s SP1. This upgrade significantly enhances scalability, security, and efficiency, enabling one-hour transaction finality, lower costs, and seamless Ethereum compatibility.

By integrating its modular architecture, EigenDA-powered data availability, and SP1’s ZK proofs, Mantle is building an institutional-grade liquidity chain for DeFi, gaming, and beyond. Developers can leverage advanced ZK technology while maintaining Ethereum’s interoperability and security standards.

The testnet launches in Q1 2025, setting the stage for next-gen decentralized applications and Mantle’s role as a leader in blockchain scalability. Stay tuned for updates as Mantle drives the future of on-chain finance, to learn more and see a roadmap to follow to know what is going on you can visit here

Upcoming Events

Mantle Network has various upcoming events in 2025 to allow individuals both new and existing to participate and learn more about what Mantle has to offer.

Web3 Connect: An Institutional-Focused Forum, taking place in Hong Kong on February 17 by 8:00 am local time.
Sozu Haus Denver 2025, taking place in Denver on February 22 by 1:00 pm local time.
Digital Asset Summit 2025, taking place in New York on March 18 by 3:00 pm local time.

To register for any of these events you can visit here

Conclusion

In this article, we've explored the Mantle network and the rich features and incentives it offers. This is just the tip of the iceberg, as Mantle continues to evolve and incentivize builders. To learn more, visit their website here, follow them on X (Twitter) here, join their Telegram here, and connect on Discord here to keep up to date and be part of the community.

Mina Under the Hood: A Technical Introduction

Adetayo Lasisi — Sat, 18 Jan 2025 14:00:36 +0000

In this article, we will explore Mina's tools and how they work together, allowing us to understand Mina and its underlying technology.

Introduction

Mina's lightweight blockchain technology provides collaborative, reusable proof of everything, which enables an internet of true things where data is verifiable, accessible, and privacy-preserving, promoting a more open and trustworthy digital world.

Mina empowers developers to build innovative digital products. Tools like 01labs and Protokit provide the necessary infrastructure, along with the zero-knowledge tech stack, which includes the Kimchi-Pickles proof system, Ouroboros Samasika POS Consensus, zkApps, Snarketplace Proof market and Snarkworkers facilitating the creation of the next generation of applications.

We begin by taking a look at the zero-knowledge tech stack

Kimchi-Pickles proof system

Proof systems are built specifically to prove statements, Mina's unique proof system is known for being highly efficient and composable, Pickles is Mina's proof system that creates recursive proofs which rely on a protocol called Kimchi to produce the proofs, this allows the Mina blockchain to remain of a fixed size of about 22kb. Mina Protocol is the only blockchain that offers infinite recursion.

Kimchi is based on PLONK, a proof system released in 2019, Since then, many improvements and extensions have been proposed. There’s been fflonk, turbo PLONK, ultra PLONK, plonkup, and recently plonky2. One common theme is all these protocols implement variants of PLONK.

Imagine Alice wants to verify Bob solved a puzzle without revealing his solution. Traditional methods require Bob to share the solution, which isn't ideal. This is where protocols like PLONK shine

A program verifying the solution is transformed into two pieces: a prover and verifier "index", not actual keys.
Bob uses the prover index, puzzle, and his solution to create a proof without revealing the solution.
Alice verifies the proof using the verifier index. If successful, she knows Bob solved the puzzle without seeing his solution.

This enables secure verification while keeping private information confidential.

Ouroboros Samasika POS Consensus

Mina employs Ouroboros Samasika, a provably secure Proof-of-Stake (PoS) protocol. Built upon the Ouroboros family based on Cardano’s Ouroboros, Samasika enhances consensus by enabling efficient block production and eliminating the need for extensive historical checks. This ensures high security while mitigating centralization risks by resolving long-range forks without relying on trusted third parties or requiring the storage of extensive blockchain history.

Like all proof of stake protocols, it requires less computing power than Bitcoin's proof of work. "Imagine Proof-of-Stake as a dart game. Your stake size determines your portion of the 'dartboard.' The larger your stake, the greater your chance of 'hitting the target' and being selected to produce the next block.

Because people’s hold on stake changes frequently, the distribution of stake on the dartboard must change as well.

In the dartboard example, the dartboard must be redrawn to recalculate the stake distribution for every epoch. Each epoch in Mina consists of 7,140 slots, and in each slot, a new dart is thrown (aka a new block is produced). As of the mainnet launch, each slot in Mina lasts 3 minutes, meaning each epoch is around 14 days. There is no minimum staking requirement with Mina. Anyone can stake their own MINA or delegate their stake to another person.

Ouroboros uses Verifiable Random Functions (VRFs) to determine block producers in a secure and decentralized manner. VRFs allow block producers to secretly determine their turn to produce a block, preventing targeted attacks.

Using random selection block production is probabilistic, based on the size of a stakeholder's stake. Multiple block producers can be chosen for a slot, enhancing security and minimizing the impact of potential attacks, In the case of multiple valid blocks for a slot, the longest chain is selected, ensuring consensus.

zkApps

zkApps leverage zero-knowledge proofs (zk-SNARKs) for secure and private computations. Developers use the zkApp CLI and o1js to build these applications. The core element is the prover function, written in o1js, which executes the zkApp's logic. This function, running in the user's browser, generates a zero-knowledge proof demonstrating the correct execution of the logic without revealing sensitive data.

For example, in a decentralized exchange, a user might use the zkApp to trade assets privately, with the proof verifying the trade's validity without disclosing trade details.

Inputs: Prover functions require both private and public inputs. Private inputs remain confidential, while public inputs are shared for verification.

Verification: The verifier function, efficiently executed by the Mina network, validates the proof against the defined constraints.

Efficiency: Regardless of prover function complexity, verification remains swift and efficient.

To use a zkApp, end users must Install a Wallet that supports interactions with zkApps.

After a zkApp is deployed to a host, end users can interact with it:

The user visits funzkapp.com.
The user interacts with the zkApp and enters the required data. For example, if this were an automated market maker, the user might specify to buy x amount of ABC at y price.
The prover function in the zkApp generates a zero-knowledge proof locally using the data entered by the user.

This data can be either:

Private, the data is never seen by the blockchain.
Public, the data is stored on-chain or off-chain, depending on what the zkApp specified as required for a given use case.

A list of state updates called account updates, which will be created by the transaction is generated. The account updates are associated with this proof.

The user selects Submit to chain in the zkApp UI.

The user confirms the transaction on their wallet.
The wallet signs the transaction containing the proof and the associated description of the state to update.
The wallet sends the transaction to the Mina network.

The Mina network receives this transaction and verifies that the proof successfully passes the verifier method listed on the zkApp account. If the network accepts this transaction, this proof and the requested state changes are valid and are allowed to update the zkApp state.

The end user's privacy is maintained because their interaction occurs locally in a web browser using JavaScript on the client. The zkApp account gets updated on-chain. When the prover function runs in a web browser, the smart contract outputs proof and some associated data called "account updates" that are sent to a zkApp address as part of the transaction.

The integrity of these account updates is ensured by passing a hash of the account updates as public input to the smart contract. The account updates must be present and unmodified for the verification function to pass successfully when it runs on Mina. This allows the Mina network to confirm the integrity of both the proof and the associated account updates

There are two zkApp state

On-chain state describes the state that lives on the Mina blockchain. Each zkApp account provides 8 fields of 32 bytes each of arbitrary storage. You may store anything here as long as it fits in the size provided. If the state is to be larger, or if the state accumulates per user within your zkApp, then the best option is to use off-chain state
Off-chain state describes the state stored anywhere else. For larger data, you might want to consider storing the root of a Merkle tree or a similar data structure within your zkApp's on-chain storage that references self-hosted off-chain state stored elsewhere. Mina doesn't offer an out-of-the-box solution for off-chain storage

When the zkApp runs in a user's web browser, it can insert state to an external storage, such as IPFS. When the transaction is sent to the Mina network, if it accepts this zkApp transaction then proof and state are known to be valid so the updates are allowed, then the zkApp transaction can update the root of the Merkle tree that is stored onchain.

With this knowledge, we will explore zkApps further by building one after we get an introduction to o1js and its basic concepts.

Snarketplace Proof market and Snark Workers

The Snarketplace is a service exchange where block producers add transactions for SNARK Workers to create ZKPs and process them. This marketplace model ensures the network’s compact size and efficient transaction processing by requiring completed SNARK work to be purchased before adding new block producer transactions.

While most protocols have just one primary group of node operators (often called miners, validators, or block producers), Mina has a second group — the SNARK worker.

SNARK workers are integral to Mina's operation. They produce the zero-knowledge proofs (SNARKs) that verify the validity of each block. These proofs are essential for maintaining Mina's succinctness, allowing nodes to discard historical data and retain only the latest SNARK, significantly reducing storage requirements.

The reason for this is each block producer, when they propose a new block to the network, must also include a zk-SNARK along with that block. This allows nodes to discard all historical data that's been finalized, and retain just the SNARK.

While block producers generate SNARK proofs for blocks, individual transactions within those blocks also require to be SNARKED. This is crucial because the blockchain-level SNARK only verifies the integrity of the block itself, not the validity of the transactions included within it.

For example: Imagine the current blockchain state is represented by hash 'a6f8792226...'. A new block arrives with a state hash '0ffdcf284f...' and an accompanying SNARK. This SNARK proves that a block exists which extends the blockchain with the previous state hash 'a6f8792226...'. However, this SNARK doesn't guarantee the validity of the transactions within that new block. A malicious block producer could include invalid transactions without being detected by this blockchain-level SNARK.

To address this, each transaction within a block also requires its own individual SNARK, ensuring the validity of all included transactions.

To ensure that nodes can operate without trust on the Mina blockchain, it is important that each node can verify the state of the chain without needing to replay the transactions. For this to work, the blockchain SNARK is not enough. We need to know that the transactions are also valid.

Individually generating SNARKs for each transaction is inefficient. This leads to slow block times due to the high computational cost and difficulties in handling asynchronous transaction arrivals. Lucky for us, we can leverage two properties about SNARKs:

proofs can be merged - two proofs can be combined to form a merge proof
merges are associative - merge proofs are identical, regardless of the order merged

What these two properties essentially allow us to do is take advantage of parallelism. If proofs can be merged, and it doesn't matter how they're combined, then SNARK proofs can be generated in parallel. Whichever proof is finished first can be combined later with the proofs in progress.

This can be envisioned as a binary tree, where the bottom row (the leaves) consists of the individual transaction proofs, and each parent row is the set of respective merge proofs. We can combine these to the root, which represents a state update performed by applying all the transactions.

Next, let's focus on the practical implementation. We'll discuss how to utilize 01js and Protokit to develop zkApps on the Mina platform.

o1js

o1js is a TypeScript library for writing general-purpose zero knowledge (zk) programs and writing zk smart contracts for Mina. As with any library for building projects, we need to have an understanding of the fundamental concepts, this helps us know the appropriate steps to take when we want to create our applications.

Basic concepts

Field Field elements are the basic unit of data in zero-knowledge-proof programming. Each field element can store a number up to almost 256 bits in size. You can think of a field element as a uint256 in Solidity.

For Example

// For example, in typical programming, you might use:
const sum = 1 + 3.

// In o1js, you write this as:
const sum = new Field(1).add(new Field(3))

Built-in data types

Some common data types found in 01js

new Bool(x);   // accepts true or false
new Field(x);  // accepts an integer, or a numeric string if you want to represent a number greater than JavaScript can represent 
but within the max value that a field can store.
new UInt64(x); // accepts a Field - useful for constraining numbers to 64 bits
new UInt32(x); // accepts a Field - useful for constraining numbers to 32 bits

PrivateKey, PublicKey, Signature; // useful for accounts and signing
new Group(x, y); // a point on our elliptic curve, accepts two Fields/numbers/strings
Scalar; // the corresponding scalar field (different than Field)

CircuitString.from('some string'); // string of max length 128

In the case of Field and Bool, you can also call the constructor without new:

let x = Field(10);
let b = Bool(true);

Conditionals

Unlike conditional statements common in programming, traditional conditional statements are not supported by o1js

// this will NOT work
if (foo) {
  x.assertEquals(y);
}

Instead, use the o1js built-in Circuit.if() method, which is a ternary operator:

const x = Circuit.if(new Bool(foo), a, b); // behaves like `foo ? a : b`

Functions

Functions work as you would expect in TypeScript.

function addOneAndDouble(x: Field): Field {
  return x.add(1).mul(2);
}

Common methods

Some frequently used common methods are

let x = new Field(4); // x = 4
x = x.add(3); // x = 7
x = x.sub(1); // x = 6
x = x.mul(3); // x = 18
x = x.div(2); // x = 9
x = x.square(); // x = 81
x = x.sqrt(); // x = -9

let b = x.equals(8); // b = Bool(false)
b = x.greaterThan(8); // b = Bool(true)
b = b.not().or(b).and(b); // b = Bool(true)
b.toBoolean(); // true

let hash = Poseidon.hash([x]); // takes array of Fields, returns Field

let privKey = PrivateKey.random(); // create a private key
let pubKey = PublicKey.fromPrivateKey(privKey); // derive public key
let msg = [hash];
let sig = Signature.create(privKey, msg); // sign a message
sig.verify(pubKey, msg); // Bool(true)

For a full list, see the o1js reference here.

Recursion

As mentioned above Kimchi, the custom proof system that backs o1js, supports arbitrary infinite recursive proof construction of circuits through integration with the Pickles recursive system.

Recursion is an incredibly powerful primitive that has a wide array of uses. Generally, you can use recursion to verify any zero knowledge program as part of your zkApp. Some examples are:

Mina uses linear recursive proofs to compress the blockchain, an infinitely growing structure, down to a constant size.
Mina also uses "rollup-like" tree-based recursive proofs to, parallel, compress transactions within blocks down to a constant size.
An app-specific rollup like a Mastermind game that uses linear recursive proofs to progress the state machine of the application without needing to sync back to the game.
App-specific rollups can use recursion to communicate with each other, like app chains using Inter-Blockchain Communication protocol or parachains using Cross-Chain Virtual Machines to send messages.

In o1js, you can use ZkProgram() to define the steps of a recursive program. Like SmartContract() methods, ZkProgram() methods execute off-chain.

After performing the desired recursive steps, you can settle the interaction on Mina's blockchain by embedding ZkProgram within a SmartContract method that verifies the underlying proof of execution and extracts the output that can be used elsewhere in the method like storing the output in app-state.

This simple example has only one method that proves the public input it received is zero:

import { Field, ZkProgram } from 'o1js';

const SimpleProgram = ZkProgram({
  name: 'simple-program-example',
  publicInput: Field,

  methods: {
    run: {
      privateInputs: [],

      async method(publicInput: Field) {
        publicInput.assertEquals(Field(0));
      },
    },
  },
});

To compile this program

const { verificationKey } = await SimpleProgram.compile();

Now, you can use it to create a proof

const { proof } = await SimpleProgram.run(Field(0));

To verify this proof from within any method of your SmartContract class:

@method async foo(proof: SimpleProgram.Proof) {
  proof.verify().assertTrue();
  const output: Field = proof.value;
  // ...the rest of our method.
  // For example, storing the output of the execution of the program we've
  // proven as on-chain state, if desired.
}

In this example, foo is taking the SimpleProgram proof as a private argument to the method, verifying that the execution was valid, and then using the output.

You can find more examples and use cases here

It is time for us to see o1js in action

We are going to start with some prerequisites, it is mandatory to have zkApp CLI installed and this can be done with this command

npm install -g zkapp-cli

In our terminal, we'll create a new project with this command

zk project 01-hello-world

The zk project command has the ability to scaffold the UI for your project. For this tutorial, select none:

 Create an accompanying UI project too? …
  next
  svelte
  nuxt
  empty
> none

Our expected output is going to be:

✔ Create an accompanying UI project too? · none
✔ UI: Set up project
✔ Initialize Git repo
✔ Set up project
✔ NPM install
✔ NPM build contract
✔ Set project name
✔ Git init commit

Success!

Next steps:
  cd 01-hello-world
  git remote add origin <your-repo-url>
  git push -u origin main

The zk project command creates a 01-hello-world directory that contains the scaffolding for your project, including tools such as the Prettier code formatting tool, the ESLint static code analysis tool, and the Jest JavaScript testing framework.

We can move into the 01-hello-world with its command

cd 01-hello-world

// we can list the items in the directory with
ls

Before we begin, we need to do a clean-up by deleting some old files with these commands

rm src/Add.ts
rm src/Add.test.ts
rm src/interact.ts

Then we can create new files with these commands

zk file src/Square
touch src/main.ts

The zk file command creates the src/Square.ts and src/Square.test.ts test files. Now we open src/index.ts in a text editor and change it to look like

import { Square } from './Square.js';

export { Square };

The src/index.ts file contains all of the exports we want to make available for consumption from outside our smart contract project, such as from a user interface.

Now we have this set up let's write the smart contract, in the src/Square.ts file, we import

import {
  Field,
  SmartContract,
  state,
  State,
  method,
} from 'o1js';

Each item in the import are

Field: The native number type in o1js.
SmartContract: The class that creates zkApp smart contracts.
state: A convenience decorator used in zkApp smart contracts to create references to state stored on-chain in a zkApp account.
State: A class used in zkApp smart contracts to create a state stored on-chain in a zkApp account.
method: A convenience decorator used in zkApp smart contracts to create smart contract methods like functions. Methods that use this decorator are the end user's entry points to interacting with a smart contract.

In the same file, we add the smart contract called Square has one element of on-chain state named num of type Field as defined by the following code

export class Square extends SmartContract {
  @state(Field) num = State<Field>();
}

As mentioned earlier zkApps can have up to eight fields of on-chain state. We add init method to the code to set up the initial state of the smart contract on deployment

  init() {
    super.init();
    this.num.set(Field(3));
  }

Since this code extends SmartContract it has its own initialization to perform, calling super.init() invokes this function on the base class. Then, this.num.set(Field(3))initializes the on-chain state num to a value of 3.

Finally, we add an update() function


  @method async update(square: Field) {
    const currentState = this.num.get();
    this.num.requireEquals(currentState);
    square.assertEquals(currentState.mul(currentState));
    this.num.set(square);
  }

When put together, it should look like this

import { Field, SmartContract, state, State, method } from 'o1js';

export class Square extends SmartContract {
  @state(Field) num = State<Field>();

  init() {
    super.init();
    this.num.set(Field(3));
  }

  @method async update(square: Field) {
    const currentState = this.num.get();
    this.num.requireEquals(currentState);
    square.assertEquals(currentState.mul(currentState));
    this.num.set(square);
  }
}

The function name update is arbitrary, but it makes sense for this example. Notice how the @method decorator is used because it is intended to be invoked by end users by using a zkApp UI, or as in this case, the main.ts script.

This method contains the logic by which end users are allowed to update the zkApp's account state on chain. A zkApp account is an account on the Mina blockchain where a zkApp smart contract is deployed. A zkApp account has a verification key associated with it.

In our example:

If the user provides a number for example, 9 to the update() method that is the square of the existing on-chain state referred to as num for example, 3, then update the num value that is stored on-chain to the provided value in this case, 9.
If the user provides a number that does not meet these conditions, they are unable to generate proof or update the on-chain state.

These update conditions are accomplished by using assertions within the method. When a user invokes a method on a smart contract, all assertions must be true to generate the zero knowledge proof from that smart contract. The Mina network accepts the transaction and updates the on-chain state only if the attached proof is valid. This assertion is how you can achieve predictable behaviour in an off-chain execution model.

Notice that get() and set() methods are used for retrieving and setting on-chain state.

A smart contract retrieves the on-chain account state when it is first invoked if at least one get() exists within it.

Similarly, using set() changes the transaction to indicate that changes to this particular on-chain state are updated only when the transaction is received by the Mina network if it contains a valid authorization (usually, a valid authorization is proof).

For the next step, we need to interact with a smart contract, we will write a script that interacts with your smart contract. As before, the complete main.ts example file is provided. In the main.ts file we are going to do the following

import { Square } from './Square.js';
import { Field, Mina, PrivateKey, AccountUpdate } from 'o1js';

Using a simulated local blockchain speeds up development and tests the behaviour of your smart contract locally, To initialize the simulated local blockchain, we add the following code from the main.ts file

const useProof = false;
 const Local = await Mina.LocalBlockchain({ proofsEnabled: useProof });
 Mina.setActiveInstance(Local);
 const deployerAccount = Local.testAccounts[0];
 const deployerKey = deployerAccount.key;
 const senderAccount = Local.testAccounts[1];
 const senderKey = senderAccount.key;

This simulated local blockchain provides pre-funded accounts. So we add these lines to create local test accounts with test MINA (tMINA) four our own use.

// ----------------------------------------------------
// Create a public/private key pair. The public key is your address and where you deploy the zkApp to
const zkAppPrivateKey = PrivateKey.random();
const zkAppAddress = zkAppPrivateKey.toPublicKey();

After we have made this changes our main.ts file should look like this

import { Square } from './Square.js';
import { Field, Mina, PrivateKey, AccountUpdate } from 'o1js';

const useProof = false;

const Local = await Mina.LocalBlockchain({ proofsEnabled: useProof });
Mina.setActiveInstance(Local);

const deployerAccount = Local.testAccounts[0];
const deployerKey = deployerAccount.key;
const senderAccount = Local.testAccounts[1];
const senderKey = senderAccount.key;
// ----------------------------------------------------

// Create a public/private key pair. The public key is your address and where you deploy the zkApp to
const zkAppPrivateKey = PrivateKey.random();
const zkAppAddress = zkAppPrivateKey.toPublicKey();

We can now build and run the smart contract, we have to first build to compile the TypeScript code into JavaScript with this command:

npm run build

Then we run the JavaScript code with

node build/src/main.js

We can combine to make it run in one command with

npm run build && node build/src/main.js

We have set up our environment to let us run the smart contract, we now have to move to initialize our smart contract, we are going to add more code to main.ts.

// create an instance of Square - and deploy it to zkAppAddress
const zkAppInstance = new Square(zkAppAddress);
const deployTxn = await Mina.transaction(deployerAccount, async () => {
  AccountUpdate.fundNewAccount(deployerAccount);
  await zkAppInstance.deploy();
});
await deployTxn.sign([deployerKey, zkAppPrivateKey]).send();
// get the initial state of Square after deployment
const num0 = zkAppInstance.num.get();
console.log('state after init:', num0.toString());

In the above what we are doing is:

We create a public/private key pair; the public key is an address on the Mina network where you deploy the zkApp to
We create an instance of your smart contract Square and deploy it to zkAppAddress
Then we get the initial state of Square after deployment

Then we run the below in the terminal

npm run build && node build/src/main.js

our expected output is

state after init: 3

The next thing we want to do is update zkApp account with a transaction

// ----------------------------------------------------
const txn1 = await Mina.transaction(senderAccount, async () => {
  await zkAppInstance.update(Field(9));
});
await txn1.prove();
await txn1.sign([senderKey]).send();
const num1 = zkAppInstance.num.get();
console.log('state after txn1:', num1.toString());

then we run our command again and our expected output should be

state after init: 3
state after txn1: 9

One more thing we have to explore is when a transaction fails, this gives us the full breadth to know what we are doing, the contract logic allows the number that is stored as on-chain state to be replaced only by its square. Now that num is in state 9, updating is possible only with 81. To test a failure, we add these next lines of code change the state to 75 in zkAppInstance.update(Field(75))

// ----------------------------------------------------
try {
  const txn2 = await Mina.transaction(senderAccount, async () => {
    await zkAppInstance.update(Field(75));
  });
  await txn2.prove();
  await txn2.sign([senderKey]).send();
} catch (error: any) {
  console.log(error.message);
}
const num2 = zkAppInstance.num.get();
console.log('state after txn2:', num2.toString());

Like we have done previously to test we run our command and the expected output should be

state after init: 3
state after txn1: 9
Field.assertEquals(): 75 != 81
state after txn2: 9

And finally, be sure to change your main.ts file to include the correct update to change the state to 81 in zkAppInstance.update(Field(81)). After running the command again the output should be

state after init: 3
state after txn1: 9
state after txn2: 81

We have been able to play around with o1js to see what it offers and how it powers Mina application.

We have one more topic to touch which is Protokit and what it offers us in Mina.

Protokit

Protokit is a framework for building privacy-enabled application chains a.k.a. zk-roll-apps/zk-rollups. Enabling developers to build zero-knowledge privacy-preserving applications with a minimal learning curve. The framework itself is powered by o1js, an SDK for building zkApps. All applications built with Protokit are compatible with the Mina blockchain by design and can use the Mina L1 for settlement.

Rollups

Rollups are a form of an L2 scaling solution, originating from networks such as Ethereum. L2 solutions aim to address the scalability issues of L1 networks by moving transactions off-chain, while still maintaining the security guarantees of the L1 network.

Rollups alleviate the potential race condition scenarios by moving the execution from the client side to the server/sequencer side. Protokit offers a hybrid execution model, where code can run both on and off-chain, thanks to recursive zero-knowledge proofs. This allows retaining the capabilities of smart contracts while extending them with the capabilities of sequential execution.

Application Chain

The application chain is an application-specific form of a rollup. Application-specific rollups allow developers to optimize their rollup implementation to suit their application's needs, providing a better user experience like faster block times and potentially lower fees than general-purpose rollups like zkSync.

Protokit Architecture consists of Runtime, Protocol and Sequencer, Let's break this down further.

Runtime

Runtime is the first modular component of the app chain, which contains all the business logic of the application itself. Business logic is implemented as runtime modules, defining the runtime state and runtime methods of each module.

Runtime methods are functions callable by user's transactions, responsible for reading and writing to the state following their inner business logic implementation. Each runtime module can define its own state (storage), which can be of two types: state and state map.

Protocol

Protocol is the focal point of every Protokit app chain.

Firstly it defines how state transitions generated by the rest of the framework are applied to the underlying state tree.
Secondly, it determines how proofs of state transitions are brought together with proofs of runtime execution to form a block, or at least a part of it.

Every protocol is composed of protocol modules, following the modular design of Protokit. The bare minimum protocol must always contain a StateTransitionProver and a BlockProver module.

Sequencer

Sequencer is the gateway between the user's transactions and the block production. the sequencer is responsible for accepting user's transactions into a mempool, validating them, sequencing them as part of the block production process, orchestrating the block production prover worker pipeline, and finally submitting the rollup block to the settlement layer.

All working components of the sequencer are sequencer modules and may be added, removed or replaced at the developer's convenience following the modularity principles.

With this overview, we can now get our hands dirty building a single runtime module. The runtime module would store a ledger of balances for public keys, and the current circulating supply.

We are going to use the starter kit here, navigate to packages/chain/src/balances.ts and you'll see the snippet below, one thing you'll also notice is we're making use of o1js.

import { runtimeModule, state, runtimeMethod } from "@proto-kit/module";
import { State, assert } from "@proto-kit/protocol";
import { Balance, Balances as BaseBalances, TokenId } from "@proto-kit/library";
import { PublicKey } from "o1js";

interface BalancesConfig {
  totalSupply: Balance;
}

@runtimeModule()
export class Balances extends BaseBalances<BalancesConfig> {
  @state() public circulatingSupply = State.from(Balance);

  // implicitly inherited from `BaseBalances`
  // @state() public balances = StateMap.from(..);

  @runtimeMethod()
  public addBalance(tokenId: TokenId, address: PublicKey, amount: Balance) {
    const circulatingSupply = this.circulatingSupply.get();
    const newCirculatingSupply = Balance.from(circulatingSupply.value).add(
      amount
    );
    assert(
      newCirculatingSupply.lessThanOrEqual(this.config.totalSupply),
      "Circulating supply would be higher than total supply"
    );
    this.circulatingSupply.set(newCirculatingSupply);
    this.mint(tokenId, address, amount);
  }
}

The first thing we'll be doing is testing the runtime, it is a good practice to test your runtime modules in isolation.

In the packages/chain/test/runtime/modules folder we'll navigate to our test file named balances.test.ts where we'll do the following

We'll Setup a TestingAppChain.fromRuntime, providing only the Balances module.
We Provide non-mutable configuration for the Balances module, including the totalSupply.
Then we start the application chain, which generates keypairs for testing and sets the transaction signer.
It'll forge a transaction to the Balances module, calling the addBalance method.
Then it signs and sends the transaction and produces a block for the application chain.
After that it Queries the Balances module for the balance of the test account from keypair generated earlier.
It asserts that the transaction was included in the block, while the execution of the transaction was successful.
It also asserts that the balance of the test account has been updated accordingly.

import { TestingAppChain } from "@proto-kit/sdk";
import { PrivateKey } from "o1js";
import { Balances } from "../src/balances";
import { log } from "@proto-kit/common";
import { BalancesKey, TokenId, UInt64 } from "@proto-kit/library";

log.setLevel("ERROR");

describe("balances", () => {
  it("should demonstrate how balances work", async () => {
    const appChain = TestingAppChain.fromRuntime({
      Balances,
    });

    appChain.configurePartial({
      Runtime: {
        Balances: {
          totalSupply: UInt64.from(10000),
        },
      },
    });

    await appChain.start();

    const alicePrivateKey = PrivateKey.random();
    const alice = alicePrivateKey.toPublicKey();
    const tokenId = TokenId.from(0);

    appChain.setSigner(alicePrivateKey);

    const balances = appChain.runtime.resolve("Balances");

    const tx1 = await appChain.transaction(alice, () => {
      balances.addBalance(tokenId, alice, UInt64.from(1000));
    });

    await tx1.sign();
    await tx1.send();

    const block = await appChain.produceBlock();

    const key = new BalancesKey({ tokenId, address: alice });
    const balance = await appChain.query.runtime.Balances.balances.get(key);

    expect(block?.transactions[0].status.toBoolean()).toBe(true);
    expect(balance?.toBigInt()).toBe(1000n);
  }, 1_000_000);
});

Then we run the test command with the following

pnpm run test --filter=chain --watchAll

After that is successful, we can go on to configure the app-chain, which can be configured at three different levels, the runtime, the chain and the client. We are going to start the runtime configuration, specifying the configuration of the runtime module layout.

In the packages/chain/src/runtime/index.ts we have

import { Balance } from "@proto-kit/library";
import { Balances } from "./balances";
import { ModulesConfig } from "@proto-kit/common";

export const modules = {
  Balances,
};

export const config: ModulesConfig<typeof modules> = {
  Balances: {
    totalSupply: Balance.from(10_000),
  },
};

export default {
  modules,
  config,
};

The runtime configuration above is then used to define app-chain configurations for both client and server side app-chains. One thing to keep in mind is that configuration for the rest of the app chain, namely the protocol and the sequencer is provided implicitly behind the scenes.

So our packages/chain/src/chain.config.ts and packages/chain/src/client.config.ts will look like the below respectively

import { LocalhostAppChain } from "@proto-kit/cli";
import runtime from "./runtime";

const appChain = LocalhostAppChain.fromRuntime(runtime.modules);

appChain.configure({
  ...appChain.config,
  Runtime: runtime.config,
});

// TODO: remove temporary `as any` once `error TS2742` is resolved
export default appChain as any;

import { ClientAppChain } from "@proto-kit/sdk";
import runtime from "./runtime";

const appChain = ClientAppChain.fromRuntime(runtime.modules);

appChain.configurePartial({
  Runtime: runtime.config,
});

export const client = appChain;

This helps us with the server & client configuration. With this, we can implement our own runtime module. Here we have to consider a couple of things:

What will be configurable in the module?
What data will the module store?
What methods will the module expose?

In packages/chain/src/ we will create a folder named guest-book and in there we'll have our check-in.ts

import { Field, PublicKey, Struct } from "o1js";
import { UInt64 } from "@proto-kit/library";

export class CheckInId extends Field {}
export class CheckIn extends Struct({
  guest: PublicKey,
  createdAt: UInt64,
  rating: UInt64,
}) {}

we'll want to allow users to check in in the guest book. We'll start by defining the data model, namely the CheckIn struct, which will determine what constitutes a check-in. Then we'll take the next step creating our runtime module and defining the checkIns storage property, which will map a guest to the check-in they made.

import {
  RuntimeModule,
  runtimeMethod,
  runtimeModule,
  state,
} from "@proto-kit/module";
import { StateMap, assert } from "@proto-kit/protocol";
import { PublicKey } from "o1js";
import { CheckIn } from "./check-in";

@runtimeModule()
export class GuestBook extends RuntimeModule<Record<string, never>> {
  @state() public checkIns = StateMap.from(PublicKey, CheckIn);
}

Now that we have our storage defined, we can start implementing the methods that will allow users to interact with the module. We'll define the checkIn_ method, which will allow users to check-in. Inside the guest-book folder we'll create an index.ts file where we have the following:

import {
  RuntimeModule,
  runtimeMethod,
  runtimeModule,
  state,
} from "@proto-kit/module";
import { StateMap, assert } from "@proto-kit/protocol";
import { PublicKey } from "o1js";
import { CheckIn } from "./check-in";
import { UInt64 } from "@proto-kit/library";

@runtimeModule()
export class GuestBook extends RuntimeModule<Record<string, never>> {
  @state() public checkIns = StateMap.from(PublicKey, CheckIn);

  @runtimeMethod()
  public checkIn(rating: UInt64) {
    assert(rating.lessThanOrEqual(UInt64.from(5)), "Maximum rating can be 5");
    const guest = this.transaction.sender.value;
    const createdAt = UInt64.from(this.network.block.height);
    const checkIn = new CheckIn({
      guest,
      createdAt,
      rating,
    });

    this.checkIns.set(checkIn.guest, checkIn);
  }
}

The we can extend the app-chain configuration by updating it like so in packages/chain/src/runtime/index.ts

import { Balance } from "@proto-kit/library";
import { Balances } from "./balances";
import { ModulesConfig } from "@proto-kit/common";
import { GuestBook } from "./guest-book";

export const modules = {
  Balances,
  GuestBook,
};

export const config: ModulesConfig<typeof modules> = {
  Balances: {
    totalSupply: Balance.from(10_000),
  },
  GuestBook: {},
};

export default {
  modules,
  config,
};

With this, we have just implemented a custom runtime module, At this point, we would be able to read its storage or send transactions to it from the client side app-chain. Let's continue and interact with the app-chain, the first step is to start the sequencer. we can do so by using the Protokit CLI, which is available as part of the starter kit under the following command:

pnpm env:inmemory dev --filter chain

The command above will start a local sequencer, which will be available at http://localhost:8080/graphql.

Every app-chain exposes a transaction API, which is aware of the underlying runtime configuration. This allows us to forge, sign and send transactions to the sequencer without having to worry about the internal workings of the sequencer and its mempool. Let's send a transaction, in our packages/chain/test/ we create our file for testing in a file named interaction.test.ts.

import { InMemorySigner } from "@proto-kit/sdk";
import { UInt64 } from "@proto-kit/library";
import { client as appChain } from "./../src/client.config";
import { PrivateKey } from "o1js";
import { GuestBook } from "../src/guest-book";

const signer = PrivateKey.random();
const sender = signer.toPublicKey();

describe("interaction", () => {
  let guestBook: GuestBook;

  beforeAll(async () => {
    await appChain.start();

    const inMemorySigner = new InMemorySigner();

    appChain.registerValue({
      Signer: inMemorySigner,
    });

    const resolvedInMemorySigner = appChain.resolve("Signer") as InMemorySigner;
    resolvedInMemorySigner.config = { signer };

    guestBook = appChain.runtime.resolve("GuestBook");
  });

  it("should interact with the app-chain", async () => {
    const rating = UInt64.from(3);
    const tx = await appChain.transaction(sender, () => {
      guestBook.checkIn(rating);
    });

    await tx.sign();
    await tx.send();
  });
});

In the above the code does the following

Generate a random signer keypair.
Start the client appChain and register a custom in-memory signer, which will be used to sign transactions
Resolve the GuestBook runtime module, so we can interact with it
Create a transaction, which will call the checkIn method of the GuestBook runtime module
Sign and send the transaction to the locally hosted sequencer.

We can now test by running this command

pnpm test --filter=chain ./test/interaction.test.ts

This brings us to the query API which allows us to fetch the latest state of the app-chain, using the underlying app-chain module configuration. Let's query for the latest check-in for a guest, from our GuestBook runtime module.

We can update our test file from above with

import { InMemorySigner } from "@proto-kit/sdk";
import { UInt64 } from "@proto-kit/library";
import { client as appChain } from "./../src/client.config";
import { PrivateKey, Provable } from "o1js";
import { GuestBook } from "../src/guest-book";
import { sleep } from "@proto-kit/common";

const signer = PrivateKey.random();
const sender = signer.toPublicKey();

describe("interaction", () => {
  let guestBook: GuestBook;

  beforeAll(async () => {
    await appChain.start();

    const inMemorySigner = new InMemorySigner();

    appChain.registerValue({
      Signer: inMemorySigner,
    });

    const resolvedInMemorySigner = appChain.resolve("Signer") as InMemorySigner;
    resolvedInMemorySigner.config = { signer };

    guestBook = appChain.runtime.resolve("GuestBook");
  });

  it("should interact with the app-chain", async () => {
    const rating = UInt64.from(3);
    const tx = await appChain.transaction(sender, () => {
      guestBook.checkIn(rating);
    });

    await tx.sign();
    await tx.send();

    await sleep(8000);

    const checkIn = await appChain.query.runtime.GuestBook.checkIns.get(sender);
    Provable.log("checkIn", sender, checkIn);
  });
});

And we run our test command again. One thing to note is that the starter kit comes with a user interface that makes for a flexible reusable interface however we choose to use it

Conclusion

By leveraging Protokit and 01js, we have begun to uncover the potential of zero-knowledge technology within the Mina ecosystem, opening doors to countless exciting possibilities.

Exploring the Mina Ecosystem

Adetayo Lasisi — Sat, 04 Jan 2025 13:18:05 +0000

As we explore the Mina ecosystem, we will present an overview of its necessity and its role. Furthermore, we will examine the zkApps within the ecosystem, the tools available for developing these applications, and the grants that Mina offers to support builders and developers.

Introduction

In our digital world we have a lot of our personal data scattered across different platforms, ones we actively use and others we probably forgot about. This fragmentation coupled with data silos and the spread of misinformation that plague the internet, poses a challenge to managing and handling our digital identities, which is compounded by the rise of AI and deepfakes.

Blockchain technology has brought on a new era of decentralized digital identity management. While Web2, with its centralized model, allows for multiple online personas is still vulnerable to data breaches.

Web3 offers decentralized solutions but still faces challenges in regulation and privacy. Zero-knowledge proofs, when combined with decentralized identifiers enable secure and private identity verification without revealing personal information.

Mina

Mina is a ZK blockchain with a 22KB size, enabling "proof of everything" through infinitely recursive proofs. It overcomes the limitations of traditional blockchains, which often rely on public-private key pairs and on-chain data storage. By providing a collaborative, reusable "proof of everything," Mina addresses these limitations. While the security and efficiency of these systems are improving every day, the transparency of distributed ledgers raises privacy concerns. This transparency hinders mainstream adoption by corporations and their users, who are hesitant to migrate to Web3. We also need to consider building privacy into blockchain is complex and has many regulatory concerns.

Mina, with its innovative ZKP approach, is addressing the gap between Web2 and Web3. ZKPs enable users to control their identity while providing necessary information without revealing sensitive data.

Mina’s Core Tools

o1Labs, pioneers in blockchain innovation, specializing in zero knowledge are the team behind groundbreaking technologies such as Mina Protocol and o1js. Since 2017 they have been at the forefront of designing Mina's protocol and tools that power zkApps. For a deeper dive into their roadmap, visit their website here

The tools are:
* o1js (formerly Snarkyjs)— a TypeScript library for zk-SNARKs and zkApps

* Kimchi — a modular, general-purpose, PLONK-inspired zero-knowledge-proof system.

zkOracles
o1Labs is also working on developing a new type of blockchain oracle called zkOracles. Blockchain oracles are a class of technology that knows all things from the real world and brings that information to the blockchain.

Another way to expatiate on oracles is, that we generally have all our data on web2, Oracles serve as an interface to access that web2 data and bring it on-chain.

The amazing thing about zkOracles is a unique two-step execution model, that at first proves off-chain that some computation has been performed, then it is packed up into a small proof which is verified on-chain. The off-chain computation is unique in that it can be run locally without paying any costs, allowing for the ability to perform really sophisticated and exciting operations off-chain

As we explore further, let's dive into the products currently in the ecosystem. From infrastructure and tooling for developers to wallets and in-browser zkApps, we'll select one representative product from each category. This also shows how the numerous ways Mina can be integrated.

Digital ID
zkHumans: A ZK-powered protocol decentralized protocol for secure and private programmable identity with cross-organizational utility using Zero-Knowledge Proofs and Crypto-Biometrics.
While crypto-biometrics are a first-class feature, they aren’t a hard requirement. Biometrics facilitate proof of unique and living humans (sybil-resistance). zkHumans supports a multitude of authentication factors to attest to identity ownership, including biometrics, from a multitude of sources or providers. To explore this application further, you can visit their website or their repository and whitepaper
DEX
Lumina: A zero-knowledge, KYC-enabled, enterprise-ready DEX on Mina.
It shines a new light on decentralized finance, inspired by permissioned venues for trading large asset blocks while maintaining privacy, compliance, and auditability. To explore this application further, you can visit their website and whitepaper, they also have a blog where they discuss about Lumina
Explorer
Mina Explorer: A Mina explorer with charts and analytics on expected protocol returns, locked/circulating supply, current transaction fees, pending transactions, and much more. you can visit the website to see how it works.
Gaming
CTF - Capture the flag: A competition where teams or individuals have to solve several challenges by building zkApps on Mina. The one that solves/collects the most flags the fastest wins the competition. Once each challenge has been solved successfully, the user will find a “flag” within the challenge that is proof of completion. To explore and play the game you can visit their website and you can visit the repository to see how it works.
Governance
On-chain Funding platform for builders and investors: They provide funding workflows (investments, grants, accelerators) on-chain for better transparency and lower risks for both investors and builders. Utilizing ZKPs and the privacy-preserving Mina blockchain, this innovative solution protects investors’ privacy while allowing them to engage in the funding and decision-making processes. They encourage open and transparent interactions with new standards of transparency and security, such as DAO and milestone-based vesting.
To explore further, you can visit website and their repository
Infrastructure
=nil; Foundation Bridge: An In-EVM Mina Protocol state verification that enables every state transition, every transaction made within Mina state to be proved on Ethereum directly, in a completely trustless way.
Such a full state verification, thanks to fixed Mina Protocol state proof size (~22Kb), allows to bring provable computations of various complexity made possible by Mina to Ethereum (aka bridge) without any requirements for intermediate relays.
To explore and demo how it works, you can visit their website
NFTs
CPoNE (pronounced see-poh-nee): This is a method for achieving this verification by deploying a zkApp on the Mina blockchain. This app generates proof of the endorsement’s authenticity and then bridges it to Ethereum, where the NFT is minted. In this method, they use X(formerly Twitter) as an “identity provider” since it is a widely used and popular service. To explore how it works, can visit the repository
Oracles
zkNotary: A zkOracle for Mina powered by TLSNotary. zkNotary addresses the challenge of proving data originating from TLS-secured APIs. By utilizing a two-party computation (2PC), it divides TLS session keys so anyone can create cryptographic proofs of authenticity that prove that data accessed via TLS genuinely originated from a specific REST API. This is a powerful cryptographic primitive that will enable more ZK applications.
Privacy
AdMeta: This helps Web3 projects acquire users and promote their products in a decentralized way. In AdMeta users own, control and profit from their data. The data used for ad matching is fully authorized by the user and is processed in a privacy-protected manner.AdMeta also enables Web3 content creators, and Metaverse landholders to monetize their content and land in a simple and decentralized way. To explore more you can visit their website and go through their repository to understand how it works.
Tooling
zkApp.store: A zkApp marketplace for Mina Protocol that provides a platform where developers can submit, manage, and showcase their zkApps, and users can easily discover, use, and rate the zkApp ecosystem. To discover more zkApps you can visit their website
Wallets
Clor.io: A Mina Protocol wallet to store, send, receive, and stake Mina Protocol tokens from desktop, browser, and hardware wallets. To download and use the wallets you can visit their website and explore their repository to see how it works.
zkRollups
Zeko: A Layer 2 ZK Rollup ecosystem specifically designed for zero-knowledge applications (zkApps), settled by Mina Protocol, the ultimate L1 for processing ZKPs. Its purpose is to bring higher throughput and ultra-fast transaction confirmation times, a modular stack for building custom ZK Rollups, and an L2 interoperability layer for zkApps. To explore you can visit their website and check out their repository to understand how it works.

Now we have taken a look at projects that actively use Mina, let's explore the grants Mina is providing to developers and builders.

Ecosystem Grants

In the rapidly expanding landscape of blockchain technology, zero-knowledge proofs have emerged as a powerful new primitive. Developers seeking to explore zero-knowledge's unique scalability and privacy properties actively choose Mina for its lightweight recursive design and intuitive developer experience. This has brought the need for Mina to design grant programs designed to empower developers and entrepreneurs to learn and build their ideas on the Mina Protocol.

These grants are split into these options

Navigator Grants Navigators is an ongoing developer program for builders to accelerate their ZK projects to production on Mina Protocol.

This grant program is designed for teams that are in the early to mid lifecycle of their project. The Navigators grant program provides support via growth or starter grants.

The goal is to fund at least 100 projects that enhance the Mina ecosystem this year.

Identify & onboard skilled teams swiftly & enable them to start building.
Accelerate the deployment of applications/tooling into production.

Grants are continuously awarded to skilled developers and teams based on written project proposals. The allocation of funding is determined by a Navigators Exploration Team (NExT) composed of members from Mina Foundation, o1Labs, and Mina ecosystem builders.

There are two tracks for grants:

a. Starter: Suited for teams that are new to the Mina ecosystem. Teams will be awarded up to 15,000 MINA to build a project over one month. This is an invite-only program and currently not accepting applications.

b. Growth: Suited for experienced teams in the web3/Mina ecosystem. Teams will be awarded up to 100,000 MINA to build a project that enriches the Mina ecosystem and pushes it forward, be it tooling, infrastructure, or a zkApp over 1-3 Months.

Both tracks are milestone-based and teams will need to submit a proposal that outlines at least one mid-point milestone and the final deliverable(s) in detail. The grants program is open to both solo developers and teams alike. It is open for application on a rolling basis throughout this year. You can apply for support to build existing projects or propose new projects.

For more information, see the pages for each respective track.

zkIgnite Grants zkIgnite is a cohort-based, community-governed innovation fund for experienced ZK builders and entrepreneurs in the Mina ecosystem. This program is designed to support developers with key resources and grants to turn their ideas and passion projects into full-fledged businesses. The allocation of funding is determined by a team of electors from the Mina community.

So far, zkIgnite has financed 80 ZK applications and developer tools that are expanding the possibilities within the Mina Protocol, via Cohort 1, Cohort 2, and Cohort 3.

You can get involved in one of the two available tracks

a. zkApp Product: In this track, developers are to build consumer applications leveraging zero-knowledge proofs to solve real-world problems. Both teams and individual contributors are welcome, with teams encouraged to have at least 1-2 technical developers.

b. Developer Tooling and Infrastructure: In this track developers create tools that make it easier to build on Mina Protocol, enhancing efficiency for fellow developers.

For more information, see this link

Core Grants Core is a grant program that funds public goods and addresses current infrastructure needs on Mina Protocol through an RFP (Request for Proposals) process. These grants are allocated on a rolling basis and are specific in scope. They focus on supporting high-priority development areas, including token standards, zkOracles, Data Availability layers, new development features, and more.

There are two types of Core grant tracks

a. Ecosystem Advancement: Here, the focus is on proposals originating from RFCs, covering specific scopes and deliverables.

b. Public Goods: This aims to support new developments, maintenance, or enhancement of Mina Protocol.

To explore this grant further, you can go to this link

Foundation program

The Mina Foundation, a non-profit, supports the Mina Protocol and its ecosystem by working with ecosystem partners to support network health and security, administering grant programs to community members who make significant contributions, fostering community growth, and enhancing the vibrancy of the Mina ecosystem.

The Mina Foundation Delegation Program delegates voting power associated with tokens held by the Mina Foundation to a group of third-party block producers in Mina Foundation's commitment to decentralization. Block producers are objectively and transparently chosen based on their uptime performance. For more details on how to get started, you can visit the website

With a major upgrade of Mina Protocol coming soon, plus bridges and other critical tooling in progress, now is the time to start building. Mina’s TypeScript framework for zkApps makes it easy and provides unique recursion properties that make your smart contracts composable and efficient.

Conclusion

This glimpse into the Mina ecosystem only scratched the surface. Dive deeper into Mina by exploring their resources and official channels:

Website: link here
Youtube: link here
Telegram: link here
Discord: link here
X(formerly Twitter): link here

Introductions to zk-SNARKs technology in Mina Protocol

Adetayo Lasisi — Thu, 12 Dec 2024 09:41:44 +0000

Zk-snarks stands for Zero-Knowledge Succinct Non-Interactive Argument of Knowledge. It refers to a proof construction in which one can prove possession of certain information utilizing a concept known as a "zero-knowledge proof."

A zero-knowledge proof allows a prover to convince a verifier of a statement's truth without disclosing additional information. For example, a prover could demonstrate knowledge of a number's hash without revealing the number itself.

In a zero-knowledge proof of knowledge, the prover can convince the verifier not only of the existence of a piece of information but also of their possession of that information. In the context of password authentication, this would involve proving knowledge of the correct password without exposing the password itself.

Another way to look at this is to think of a locked treasure chest, You, the prover, want to show someone (the verifier) that you know the secret code to unlock the chest, but you don’t want to reveal the code itself. Instead, you open the chest, let the verifier see the treasure inside, and then lock it again. The verifier is convinced you know the code because they saw the chest open and close but they still don’t know the code itself.

“Succinct” zero-knowledge proofs can be verified within a few milliseconds, with a proof length of only a few hundred bytes even for statements about programs that are very large. In the first zero-knowledge protocols, the prover and verifier had to communicate back and forth for multiple rounds, but in “non-interactive” constructions, the proof consists of a single message sent from the prover to the verifier.

Zero-knowledge proofs are characterized by their succinctness and non-interactivity.

Succinctness: Proofs can be verified very quickly, often within milliseconds, and are typically only a few hundred bytes long, even for complex statements.
Non-interactivity: The proof consists of a single message from the prover to the verifier, eliminating the need for multiple rounds of interaction.

The most efficient way to produce zero-knowledge proofs that are non-interactive and short enough to publish to a blockchain is to have an initial setup phase that generates a common reference string shared between the prover and the verifier. We refer to this common reference string as the public parameters of the system.

To achieve these properties, many zero-knowledge proof systems rely on a common reference string (CRS), also known as public parameters. This string is generated through a setup phase and is shared between the prover and the verifier.

While this approach enables efficient and non-interactive proofs, it introduces a trust assumption: if someone gains access to the secret randomness used to generate the CRS, they could potentially create fraudulent proofs.

If someone had access to the secret randomness used to generate these parameters, they would be able to create false proofs that would look valid to the verifier.

How did it come about

Early cryptocurrency enthusiasts, particularly in the Bitcoin community, have always envisioned a future where digital transactions could be conducted anonymously and without the need for intermediaries. The nature of Bitcoin addresses seemed to offer a degree of privacy, as users could transact without revealing their real-world identities.

However, as the technology matured, it became increasingly clear that Bitcoin's level of privacy was insufficient. Data scientists, hackers, and law enforcement agencies developed techniques to remove the anonymity of users by analyzing on-chain data and correlating it with other information sources.

Characteristics of zk-SNARKs

They don't leak information.
Tiny and easy to verify.
They don't require back-and-forth communication.
They are proofs of knowledge.

Mina’s zk-SNARKs Possibilities

Mina Protocol uses zk-SNARK technology and takes it to a new level by using recursion so that no matter how many transactions or blocks are added to the chain, the computations stay small, scalable, and efficient. Mina’s smart contracts, zkApps, also leverage zk-SNARKs making it especially powerful to enable privacy & security allowing you to keep your data on a local device while only sharing proof of it on the chain.

Mina does this by proving that there exists a sequence of blocks that form a blockchain, rather than revalidating the full sequence of blocks every time a new block is created, the proof statement is slightly tweaked, Mina proves that there was a valid proof for some sequence of blocks and an extra one that is also valid. Every time a new block is created and broadcast throughout the network, the proof is extended to support this extra block

One big advantage of this is when a proof refers to itself it doesn't increase the size of proofs, no how many times a reference is made. "Mina’s self-referential concept of proofs is like a picture of a picture"

Mina is building a secure, democratic future by creating a private gateway between the real world and crypto. With its unique privacy features and ability to connect to any website, Mina is redefining the way we interact with the digital world.

zk-SNARKs opens the possibilities for new blockchain use cases such as sensitive data like your credit score, home address, medical information, and more. An example of this is Teller, Teller and Mina work together to prove a customer's credit score to secure a loan without revealing private information.

To get started with building zk-SNARK apps on Mina protocol, you can go to their docs.

References

https://z.cash/learn/what-are-zk-snarks/
https://www.investopedia.com/terms/z/zksnark.asp
https://minaprotocol.com/blog/what-are-zk-snarks
https://minaprotocol.com/blog/zk-you-should-know-snarks-starks
https://blog.zkbob.com/zksnarks-explained-how-zkbob-achieves-anonymity-in-blockchain-transactions/
https://medium.com/@bhaskark2/understanding-zero-knowledge-proofs-part-1-verifiable-computation-with-zk-snarks-ba6cbb8e6001
https://blockofchain.medium.com/mina-snark-workers-e37de54ef2a2#:~:text=Mina%20Protocol%20uses%20zk%2DSNARKs,or%20proofs%2C%20that%20validate%20transactions.

Forem: Adetayo Lasisi

createthings — A Creative System Built on Notion MCP

What I built

Video Demo

The code

adetyaz / create-things

createthings — A Creative OS Built on Notion MCP

Developing

Building

Who It Is For

The Feature Set

The Technical Architecture

The Six Databases

Technology Choices

How I Used Notion MCP

The Specific Operations

Why a Dedicated MCP Layer

What I Learned

FitTogether: Building a Social Community for Local Fitness

The Community

What I Built

Demo

Code

Github Repo and Walkthrough Demos

adetyaz / fittogether

https://fittogether-five.vercel.app/

FitTogether

Walkthrough Videos

What It Does

How I Built It

User Stories (Summary)

Busyness

Buddy Finder

Challenges

Profile & Auth

Safety

Let's begin the year with a bang!!

About Me

Portfolio

How I Built It

Tech Stack

What I'm Most Proud Of

カイア アジアのオンチェーンの未来

はじめに

BFTベースのパブリック・ブロックチェーンとは？

カイアの特徴と狙い

カイアのエコシステム

カイア・ポータル

カイア・ポータル・ミッション エポック#1 インセンティブデザイン

カイア・リワード

権利確定

パートナー・プロジェクト報酬

報酬分配

カイア・ポータルの探索

スワッピング

BinanceからあなたのウォレットへKAIAを送金する

高APRとインセンティブ戦略

Grants and Bounties

助成金の種類

報奨金プログラム

報奨金の種類

結論

Mina Meme Series & Telegram Stickers

Kaia: Powering Asia On-Chain Future

Introduction

What is a BFT-based public blockchain

Features and Aim of Kaia

The Kaia Ecosystem

Kaia Portal

Kaia Portal Mission Epoch #1 Incentive Design

Kaia Rewards

Vesting

Partner Project Rewards

Reward Distribution

Exploring the Kaia Portal

Bridging on the Kaia portal

Swapping

Sending KAIA from Binance to your wallet

Strategies for High APR and Incentives

Grants and Bounties

カイアアジアのオンチェーンの未来

カイア・ポータル・ミッションエポック#1 インセンティブデザイン