geomind_research/holo_ledger
18
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

compare ease of development near/holochain #4

New issue
Closed
opened 2026-01-06 08:20:23 +00:00 by despiegk · 1 comment
despiegk commented 2026-01-06 08:20:23 +00:00
Owner
Copy link

Story: Build a Fixed-Rate Liquidity Pool

Holochain vs NEAR – Dev Productivity Benchmark

Goal

Measure how easy and fast it is to build a non-trivial financial app on:

  • Holochain
  • NEAR

Starting from a short spec and using an AI agent.

App Definition (Same on Both)

Fixed-Rate Liquidity Pool

  • Multiple assets (e.g. USD, EUR, GOLD, SPORE)
  • Admins set fixed exchange rates between asset pairs
  • Users have accounted positions per asset
  • No order book, no AMM math
  • Deterministic accounting

Core Requirements

Roles

  • Admin

    • Set / update exchange rates
    • Enable / disable asset pairs

  • User

    • Deposit assets
    • Withdraw assets
    • Swap assets at fixed rates

Accounting Model

  • System always knows:

    • Position of every user
    • Total pool balances per asset

  • No fractional ambiguity

  • No negative balances

Operations

  1. deposit(user, asset, amount)
  2. withdraw(user, asset, amount)
  3. set_rate(admin, asset_a, asset_b, rate)
  4. swap(user, asset_a, asset_b, amount)
  5. get_positions(user)
  6. get_pool_state()

Platform Comparison Requirements

1. Bootstrapping

Measure:

  • Time from empty repo → running node
  • Number of required concepts before coding
  • AI agent success rate without human correction

2. Development Velocity

Measure:

  • Time to implement full accounting logic
  • Amount of boilerplate vs business logic
  • Error clarity during development

3. State & Consistency

Evaluate:

  • How global accounting is expressed
  • How invariants are enforced
  • How easy it is to reason about correctness

4. Client Interaction

Requirements:

  • Rust client can:

    • Deposit
    • Swap
    • Query balances

  • Minimal config / ceremony

5. Change Scenario (Critical)

Add:

  • New asset
  • New admin-only rule (e.g. max swap per tx)

Measure:

  • Code changes required
  • Risk of breaking state
  • Migration effort

AI-Assisted Benchmark

Explicitly record:

  • Can AI generate:

    • Data model
    • Core logic
    • Validation rules

  • Where AI fails:

    • Mental model errors
    • Missing invariants
    • Platform-specific pitfalls

Comparison Output (Per Platform)

  • ⏱ Time to working app
  • 📄 Lines of code
  • 🧠 Concepts required
  • 🤖 AI friction points
  • 🔧 Refactor difficulty

Definition of Done

  • Same app works on both platforms
  • Deterministic accounting verified
  • Admin pricing enforced
  • Users can deposit, swap, withdraw
  • Clear conclusion on which platform is more productive and why

on near we have already done something like this, was very easy < 1h

# Story: Build a Fixed-Rate Liquidity Pool **Holochain vs NEAR – Dev Productivity Benchmark** ## Goal Measure **how easy and fast it is to build a non-trivial financial app** on: * **Holochain** * **NEAR** Starting from a short spec and using an **AI agent**. --- ## App Definition (Same on Both) ### Fixed-Rate Liquidity Pool * Multiple assets (e.g. USD, EUR, GOLD, SPORE) * **Admins set fixed exchange rates** between asset pairs * Users have **accounted positions** per asset * No order book, no AMM math * Deterministic accounting --- ## Core Requirements ### Roles * **Admin** * Set / update exchange rates * Enable / disable asset pairs * **User** * Deposit assets * Withdraw assets * Swap assets at fixed rates --- ### Accounting Model * System always knows: * Position of **every user** * Total pool balances per asset * No fractional ambiguity * No negative balances --- ### Operations 1. `deposit(user, asset, amount)` 2. `withdraw(user, asset, amount)` 3. `set_rate(admin, asset_a, asset_b, rate)` 4. `swap(user, asset_a, asset_b, amount)` 5. `get_positions(user)` 6. `get_pool_state()` --- ## Platform Comparison Requirements ### 1. Bootstrapping Measure: * Time from empty repo → running node * Number of required concepts before coding * AI agent success rate without human correction --- ### 2. Development Velocity Measure: * Time to implement full accounting logic * Amount of boilerplate vs business logic * Error clarity during development --- ### 3. State & Consistency Evaluate: * How global accounting is expressed * How invariants are enforced * How easy it is to reason about correctness --- ### 4. Client Interaction Requirements: * Rust client can: * Deposit * Swap * Query balances * Minimal config / ceremony --- ### 5. Change Scenario (Critical) Add: * New asset * New admin-only rule (e.g. max swap per tx) Measure: * Code changes required * Risk of breaking state * Migration effort --- ## AI-Assisted Benchmark Explicitly record: * Can AI generate: * Data model * Core logic * Validation rules * Where AI fails: * Mental model errors * Missing invariants * Platform-specific pitfalls --- ## Comparison Output (Per Platform) * ⏱ Time to working app * 📄 Lines of code * 🧠 Concepts required * 🤖 AI friction points * 🔧 Refactor difficulty --- ## Definition of Done * Same app works on both platforms * Deterministic accounting verified * Admin pricing enforced * Users can deposit, swap, withdraw * Clear conclusion on **which platform is more productive and why** --- > on near we have already done something like this, was very easy < 1h
lee commented 2026-01-09 16:13:42 +00:00
Member
Copy link

Implemented with AI (Claude Code - Opus 4.5) on both platforms.

Flow:

  • Ask AI to create plan based on requirements/goals
  • Revise plan, e.g. don't use nix setup for holochain but instead create the directory layout manually, and use system installed tools like holochain and hc
  • Installed cargo-near locally so the near project can be bootstrapped more easily
  • Complete work on 1 platform, then move on to the next

After the planning stage both implementations were done in around 1 hour. Near appeared to be slightly faster. In both cases, there were some issues with dependecy versions. Specifically, for holochain it initially implemented calls with a wrong signature, this was corrected after it compiled the documentation and looked at it. After getting it to work it also refactored to remove deprecated calls. For near, there were some initial compilation issues due to dependecies where the latest version does not compile on the pinned rust version (boostrapping the near project pins the rust compiler to 1.86 currently, down from the current 1.92 latest release). After noticing this it immediately downgraded the affected components and continued implementation. In both cases, issues were handled without user intervention. In the case of near, the argument could be made to remove the pinned rust compiler version, though with wasm this might lead to other errors down the line which could increase development time (there is likely a reason the compiler version gets pinned by the near team).

All in all performance on both platforms seems comparable.

Implemented with AI (Claude Code - Opus 4.5) on both platforms. Flow: - Ask AI to create plan based on requirements/goals - Revise plan, e.g. don't use nix setup for holochain but instead create the directory layout manually, and use system installed tools like `holochain` and `hc` - Installed `cargo-near` locally so the near project can be bootstrapped more easily - Complete work on 1 platform, then move on to the next After the planning stage both implementations were done in around 1 hour. Near appeared to be slightly faster. In both cases, there were some issues with dependecy versions. Specifically, for holochain it initially implemented calls with a wrong signature, this was corrected after it compiled the documentation and looked at it. After getting it to work it also refactored to remove deprecated calls. For near, there were some initial compilation issues due to dependecies where the latest version does not compile on the pinned rust version (boostrapping the near project pins the rust compiler to 1.86 currently, down from the current 1.92 latest release). After noticing this it immediately downgraded the affected components and continued implementation. In both cases, issues were handled without user intervention. In the case of near, the argument could be made to remove the pinned rust compiler version, though with wasm this might lead to other errors down the line which could increase development time (there is likely a reason the compiler version gets pinned by the near team). All in all performance on both platforms seems comparable.
lee closed this issue 2026-01-09 16:13:42 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
lee
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
geomind_research/holo_ledger#4
No description provided.