by Unity Nodes
Developer Relations

High-Level Kotlin SDK built on near-jsonrpc-client (KMP) – Mobile & JVM Ecosystem Gap

1 posts53 views1 likesLast activity Feb 2026

Open on Forum
  1. 0xkaramiOP 1

    As NEAR adoption grows, mobile-native and Kotlin/JVM developers need a high-level, production-ready SDK to build apps efficiently and reduce friction. While JavaScript and Rust already have mature SDKs, Kotlin lacks an equivalent, even though a low-level RPC client exists. This post outlines the current landscape, identifies the gap, and proposes a new High-Level Kotlin SDK built on the existing multiplatform RPC client.

    Current Status of NEAR SDKs

    Generated clients (low-level RPC clients):

    • Rust

    • TypeScript

    • Swift

    • Kotlin (built by me)

    • Python (built by me)

    High-Level Clients (abstraction layer / dApp-ready):

    • Rust

    • TypeScript

    • Python

    • Kotlin → not yet available

    • Swift → not yet available

    This clearly shows a gap in ecosystem-level support for Kotlin, even though the low-level client already exists.

    I have already developed the low-level RPC clients for Kotlin and Python, providing a robust foundation for a high-level SDK.

    Problem Statement

    Currently, Kotlin developers must rely on raw JSON-RPC calls, low-level wrappers, or JavaScript bridges. This slows development for Android wallets, Kotlin backend services, and multiplatform dApps, and increases the likelihood of bugs or integration issues.

    Existing Work – Infrastructure Already Built

    I have developed the low-level RPC clients:

    1. Kotlin Multiplatform: near-jsonrpc-client-kotlin

      • Coroutine-first

      • Multi-platform transport (Android, JVM, Native)

      • Typed RPC calls & serialization

    2. Python: near-jsonrpc-client-py

      • Typed RPC calls

      • Retry & timeout

      • Structured error handling

    Proposal

    Develop a High-Level Kotlin SDK on top of near-jsonrpc-client-kotlin with the following MVP scope:

    Core Components:

    • Account API (getAccount(), getAccessKeys(), state)

    • Type-safe Transaction Builder (transfer, stake, functionCall, deployContract)

    • Contract API (view & call) with typed responses

    • Signer abstraction (in-memory, seed phrase, wallet selector)

    • Coroutine-first design

    • Structured error model

    Target developers:

    • Android & Kotlin JVM developers

    • Kotlin Multiplatform dApp integrators

    • Wallet developers

    Architectural Direction

    Layered design:

    1. Transport → near-jsonrpc-client-kotlin (existing low-level client)

    2. Protocol → typed NEAR primitives

    3. Execution → transaction builder & signer

    4. Developer API → account & contract abstractions

    Multiplatform advantage:

    • Core logic fully shared

    • Platform-specific layers for signing & networking

    Maintenance Commitment

    I commit to:

    • Maintaining the SDK over time

    • Aligning with NEAR protocol updates

    • Providing documentation, examples, and adoption support

    Open Questions for the NEAR Team

    • Is this aligned with NEAR’s SDK roadmap?

    • Would this be considered an official ecosystem SDK if matured?

    • Preferred path for funding/support (Foundation vs NEARN)?

Back to Discussions