Pi Network Smart Contract Status: What Developers Can Actually Do After V23?
V23 brought Soroban smart contracts to the Pi Mainnet in May 2026, marking Pi's biggest technical upgrade since Open Mainnet. However, there's a gap between 'smart contracts are on Mainnet' and 'what developers can actually do with smart contracts now,' which the official team has never explicitly clarified.
This article compiles currently available first-hand information to provide a factual status update for both general Pioneers and developers.
For General Pioneers: What Can Pi Network Do Now?
What's Confirmed to Be Possible
Pi SDK: Login and Payments This capability has existed since the early days of Pi and is unrelated to protocol upgrades. Apps within the Pi Browser can use the Pi SDK to allow users to log in with their Pi account and make payments with Pi. Most applications in the current Pi ecosystem operate using this mechanism.
Soroban Smart Contracts (Technically Ready, More Mature Than Previously Understood) After V23, Soroban smart contracts are technically ready. The official team has published the first contract example on GitHub: the Subscription Contract (PiRC2), which is quite comprehensively designed, including features like merchant service registration, user subscriptions, automatic deductions, and trial periods.
OrbitWatch further confirmed that this contract is not just a GitHub example—it has already been deployed on the Pi Testnet and is packaged within the officially released Pi SDK file (see 'Path Two' below). However, there is currently no official public statement on whether developers can actually deploy or call it.
What's Still Uncertain
Can Third Parties Call or Deploy Smart Contracts? The official team explicitly responded in Developer Discord: smart contract functionality is 'not yet finalized and is currently for internal use only; further announcements will be made when available.' Technically, it's quite mature, but the timeline for external access is unknown.
When Can PiRC1 Tokens Be Issued on Mainnet? PiRC1 defines the issuance standards for ecosystem tokens (tokens can only be issued after a product exists). Pi Launchpad has also validated the process using test tokens (IRRA, SLICE). However, there is currently no record of any third party officially completing PiRC1 review and issuing real tokens on the Mainnet.
In Summary
V23 brought 'technical feasibility,' and the completion level is higher than previously understood; however, regarding 'opening to third parties,' the official team has clearly stated—it's not yet time. Nevertheless, OrbitWatch has also observed that some developers have found ways to actually operate smart contracts without waiting for official access (see explanation below).
For Developers: What Pi Features Can You Use Now?
Path One: Pi SDK (JavaScript)
This is currently the most mature and well-documented development path.
What you can do
→ Pi Sign-in: Allow users to log into your App with their Pi account
→ Pi Payment: Allow users to pay your App with Pi
Limitations
→ Official public documentation only covers Pi.init({ version: "2.0" })
→ This version cannot call smart contract-related functions
→ Cannot issue your own ecosystem tokens
If you only need to create an App with login and payment functionality within the Pi Browser, Pi SDK (version 2.0) is currently the most reliable choice.
Path Two: Soroban Smart Contracts (Rust + SDK's Built-in SmartContract Service)
This is the new path introduced by V23. OrbitWatch's latest verification shows that this path is more complete than previously understood, but it is still not open to third parties.
Confirmed to exist, but not documented officially:
The Pi Browser automatically loads the public file sdk.minepi.com/pi-sdk.js. After reviewing this published source code, OrbitWatch confirmed:
Pi SDK already includes SmartContract service
→ Requires passing version: "3.0" during initialization (official documentation only teaches "2.0")
→ Provides submitTransaction() and pollTransaction() methods
→ Has encapsulated Subscription and NativeToken sub-modules
→ Testnet RPC URL: https://rpc.testnet.minepi.com
→ Network passphrase: Pi Testnet
→ Testnet contract addresses are built into the SDK code
In other words, what was previously stated on this page as 'Pi Testnet's Soroban RPC connection parameters are not publicly disclosed' has now been updated—these parameters indeed exist in the published SDK file, they just aren't written into public documentation like pi-platform-docs.
However, third-party calls via this official SDK path are currently rejected. Developers have reported test results in Developer Discord: calling Pi.SmartContract.submitTransaction() reaches the native bridge but returns 'App unauthorized to call this message.' The official contact confirmed that this functionality is 'not yet finalized and is for internal use only.'
Official GitHub Example:
github.com/PiNetwork/SmartContracts
→ Only one folder: contracts/subscription
→ README main page has only a title, no getting started guide
→ The entire repo has only 2 commits
Contents of the subscription contract:
This contract (corresponding to PiRC2 specifications and the Subscription module in the SDK) is quite comprehensively designed:
What merchants can do
→ register_service: Create a subscription service (set price, period, trial period)
→ process: Batch collect payments from expired subscribers
What users can do
→ subscribe: Subscribe to a service (can set auto-renewal)
→ cancel: Cancel auto-renewal
→ toggle_auto_renew: Toggle auto-renewal status
→ extend_subscription: Extend token authorization
Query functions (free to call)
→ get_service / get_subscription / is_subscription_active, etc.
The contract uses Stellar's token approve + transfer_from model for deductions, where funds remain in the user's wallet until the actual deduction, without requiring pre-locking. This is not just example code—OrbitWatch confirmed that this contract has actually been deployed on the Pi Testnet.
A New Observation: The Official Team Has Locked the 'SDK Entry Point,' Not the 'On-Chain Contract Itself'
While verifying community rumors, OrbitWatch found a Soroban escrow contract actually operating on the Pi Testnet (similar in nature to funds held for 'checkout cleaning fees' in a booking application), and directly queried the Testnet RPC to verify its existence and operational records.
Verification method: First, use the getEvents method to confirm that the contract address has a large number of real event records (states like created, funded, auto_released, etc.), then use the getTransaction method to check the full content of one transaction, and after decoding envelopeXdr, confirmed key details:
The account initiating this transaction (source_account)
→ Is a fixed wallet address (presumed to be the application's own
escrow/backend account), not the individual accounts of the user (guest)
or the host
→ In other words, this transaction was not initiated by a user
operating through the Pi Browser, triggering a Pi.SmartContract SDK call,
but rather by the developer's own system directly signing and
submitting the transaction to the Soroban RPC
This resolves a previous contradiction: the official team stated that smart contracts are 'for internal use only,' yet some developers are indeed operating contracts on the Testnet. The answer is—this developer did not use the Pi Browser's built-in Pi.SmartContract SDK (that path would still be blocked by 'unauthorized'), but rather bypassed this layer and directly operated the deployed contract using standard Soroban toolchains.
This is technically entirely reasonable: once a Soroban contract is deployed to the Testnet, it is essentially a public on-chain object. Anyone with a Testnet account can directly call it using standard Stellar/Soroban SDKs. This does not require going through the Pi Browser's native bridge, and thus naturally will not trigger the permission checks set by the Pi official team at the SDK layer.
This means the scope of official restrictions is more precise than previously understood:
What the official team has locked down
→ Call permissions for the Pi Browser's built-in Pi.SmartContract SDK
(this is the entry point the official team can control)
What the official team has not, and cannot, lock down
→ Directly operating contracts deployed on the Testnet using standard
Soroban tools (this is the nature of public on-chain data,
and is not subject to this layer of permission control if it doesn't
go through the Pi Browser)
For developers, this means: if you are willing to bypass the Pi SDK, manage your own account keys, and directly send transactions to the Soroban RPC, smart contract operations on the Testnet are technically feasible. However, doing so does not go through the officially approved SDK path, and there is currently no statement on whether the official team welcomes this approach.
Comparison of the Two Paths
Pi SDK (JS, v2.0) SmartContract (SDK v3.0)
──────────────────────────────────────────────────────────────
Primary Use Login + Payments Smart Contracts / Subscriptions / Tokens
Development Language JavaScript JavaScript SDK wrapper + Rust contracts
Official Docs Completeness Complete Not in public docs, but exists in SDK
Testnet Connection N/A Known (RPC URL, passphrase confirmed)
Call via Official SDK
Yes No (unauthorized)
Directly operate deployed
contracts (bypass SDK) N/A Technically feasible, official stance unclear
Mainnet Availability Yes Unknown
Protocol Upgrade Impact None Directly related
Entry Barrier Low Technically ready, official path not open
Unaddressed Gaps by the Official Team
Below are the questions for which OrbitWatch could not find an official timeline, listed directly:
- When will smart contract functionality be opened to third parties (via the official SDK path)? The official team only stated 'not yet finalized.'
- Does the official team approve or permit developers bypassing the Pi SDK and directly operating deployed contracts on the Testnet?
- What is the official audit progress and Mainnet launch timeline for the PiRC2 subscription contract?
- When can third parties officially issue tokens on Mainnet via the PiRC1 process?
- Why is the SmartContract service quite complete, yet it's chosen not to be included in public documentation?
These questions cannot be answered by OrbitWatch and are noted as such. If the official team provides any formal statements on the above questions, we will update this page immediately.
Further Reading
- PiRC1 Token Design Standard
- PiRC2 Subscription Contract Standard
- Smart Contracts Overview
- Pi Network Protocol Upgrade Mechanism
- Current State of Pi Ecosystem Developers: How Far Between Contribution and Reward?
Data sources: PiNetwork/SmartContracts GitHub repo (direct observation), sdk.minepi.com/pi-sdk.js (officially published SDK file, direct observation), Pi Network Developer Discord (public discussions in dev-questions channel), Pi Testnet Soroban RPC (rpc.testnet.minepi.com, direct query of getEvents/getTransaction), Pi-Defi-world/pirc-smart-contracts-explainer GitHub repo (third-party, unofficial), Pi Network Horizon API documentation. All analysis does not constitute investment advice. OrbitWatch is an independent Pi Network ecosystem observatory and is not affiliated with the official Pi Network team.
Key Points
- •V23 brought Soroban smart contracts to Pi Mainnet, but official access for third-party developers to deploy or call them via the SDK is still restricted, despite the technology being mature.
- •The Pi SDK (v2.0) supports user login and payments, but a more advanced SDK (v3.0) with smart contract capabilities, including a fully designed subscription contract (PiRC2), exists internally but is not publicly documented or authorized for external use.
- •Developers have found that they can technically bypass the official Pi SDK and directly interact with deployed Testnet Soroban contracts using standard Stellar/Soroban tools, as on-chain contracts are public, though the official team's stance on this workaround is unclear.