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

Development Developer Relations
,
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)?

1 Like