His pioneering work on PJM has earned Anton Malinovskiy recognition as the No. 1 expert in crypto payments for location-based live streaming.
During a live stream, viewers usually decide within seconds whether to support a creator. On Pyjam, they can do so without leaving the broadcast by using PJM, a digital unit operating on the Solana network.
To the user, the transfer looks like a single, straightforward action. Behind the scenes, however, it involves a complex technical process. Transaction data is recorded on Solana’s public distributed ledger rather than solely in the app’s internal database, allowing the outcome to be independently verified against on-chain data. To complete a transfer, Pyjam must identify the recipient, prepare the transaction, obtain a digital signature from the wallet, cover the network fee, and wait for final confirmation.
Anton Malinovskiy, the creator of the PJM concept, brought these stages together in a unified payment architecture. The development team implemented the system’s individual components in code.
TechBullion spoke with Malinovskiy about how the process works and how a blockchain payment can remain both convenient for viewers and independently verifiable.
Every Solana transaction requires a fee in SOL. How is that fee paid when PJM is transferred? Does the viewer need to hold SOL in their wallet beforehand?
Solana’s fee does not disappear; every transaction still has to be paid for in SOL. Under the PJM model, however, that cost can be covered by a service wallet operated as part of Pyjam’s infrastructure. Viewers do not have to buy SOL in advance and keep it in their wallets solely to support a creator.
This is made possible by a relay, which acts as an intermediary server. It receives the transaction approved by the user, verifies its signature and key parameters, and then submits it to Solana. The service wallet acts as the fee payer and covers the network fee.
Before a transfer is initiated, the application checks that the relay is available and properly configured, and that the service wallet has a sufficient SOL balance. If any of these conditions is not met, the transaction does not proceed through this route. It is therefore more accurate to say that the fee is not eliminated; when the infrastructure is operating correctly, Pyjam pays it instead of the viewer. This applies specifically to the network fee. Any service charge associated with a particular action is recorded separately.
What happens after a viewer taps the button to support a live-stream creator?
From the viewer’s perspective, the process begins by selecting an amount and confirming the action within the live stream. There is no need to copy someone else’s wallet address or switch to another application. The interface sends the server the recipient’s internal identifier, the selected amount, and, where required, information about the associated stream, chat, or message.
The server uses that identifier to locate the linked wallet. If the viewer is supporting a creator, the PJM is sent to the creator’s wallet. If the user is paying for a platform feature, a different route is used and the configured service wallet becomes the recipient. This separation establishes the purpose of the payment before the blockchain is involved.
The server then creates a payment intent that records the terms of the prospective transfer in advance: the action type, sender, recipient, amount, and any service charge. The payment intent has its own identifier, which is added to the transaction as a memo. This later makes it possible to link the on-chain transfer to a specific action within Pyjam.
Once the payment intent has been created, the embedded wallet authorizes the transaction and the system submits it to Solana, where it receives a unique transaction identifier, or txid. The server saves the txid to the payment intent, monitors the transaction’s status, and, once it has been finalized, compares the on-chain result with the original terms. Only then does the support appear in the transaction history and, for example, in the live-stream chat.
Why is a single digital signature not enough for this process?
The signatures serve different purposes. The first comes from the sender’s wallet. It provides mathematical proof that the owner approved that specific PJM transfer. The private key is never exposed, and the relay does not gain the authority to move the user’s funds independently.
After the user signs, the relay checks PJM’s token identifier on Solana, the recipient address, the amount, any separately itemized charge, and the memo. These parameters must match the payment intent created earlier. Only after that validation does the service wallet add the second signature as the fee payer, confirming that it will cover the network fee.
In other words, the user retains control over their PJM, while the infrastructure separately assumes the network cost. Preserving that boundary was essential to me: convenience should not give an infrastructure service unrestricted access to a viewer’s funds.
What happens if the connection drops and the app submits the request again?
That is a normal scenario for a mobile application, and it has to be accounted for from the outset. The connection may fail after the user taps the button but before the server’s response reaches the screen. The user cannot tell whether the transfer has started and may try again.
To prevent a single request from becoming two payments, the system uses an idempotency key, a unique identifier that protects against duplicate processing. The same key accompanies the preparation of the transaction, the registration of its result, and any permitted retries. If the app contacts the server again with that key, the process continues using the payment intent that has already been created; no new transaction is generated. If the same key is submitted with a different amount, recipient, or other changed terms, the request is rejected.
Once the transaction has been submitted, its txid is also attached to the payment intent. The same identifier cannot be registered against another transaction. A partial failure is possible as well: the transaction may already exist on Solana even though the app was unable to report the result to the server immediately. In that case, the client retains the txid, retries the registration, and checks the status of the existing payment intent instead of blindly initiating another transfer.
At what point can Pyjam tell the user that the transfer has actually been completed?
It is important not to conflate several distinct events. Tapping the button signals the user’s intent. Receiving a txid means the transaction has been created and submitted. The first network confirmation means Solana has seen the transaction. None of those events, on its own, proves that the entire payment flow has been completed correctly.
The payment intent initially receives a pending status, meaning it is awaiting processing. If a required condition is not met or an error occurs, it may move to failed. Two further states matter once the transaction has been accepted by the network. A confirmed status means that Solana has confirmed the transaction, but the result is still considered intermediate. A finalized status means the network has reached the required level of finality.
After finalization, the server validates the on-chain transaction again. It must confirm that the asset transferred was PJM, the funds reached the expected recipient, the amount matches the payment intent, the memo corresponds to its identifier, and any applicable charge is recorded separately. Only after that reconciliation does Pyjam update its internal history and balance, display a support message in the chat, or activate the paid feature. One of my core requirements was that the system should never report final success before this verification was complete.
What can be verified using Solana data, and what remains within Pyjam?
The two sources answer different questions. Solana’s public record shows what happened on-chain. Using the txid, anyone can check the transaction status, the addresses involved, PJM’s token identifier, the amount transferred, and the network fee. That information exists independently of Pyjam’s internal reporting.
The application’s record explains the purpose of the transfer: which action the user selected, which stream, chat, or message it related to, who was expected to receive the PJM, and which states the transaction passed through. The memo containing the payment-intent identifier and the txid links that internal context to the public transaction.
The user’s name, precise location, and stream content are not written to the network. Solana retains the addresses and technical transfer parameters. A public blockchain should not be described as completely anonymous, because addresses are visible to everyone and may sometimes be linked to an individual or service through external data. Our approach was therefore based not on a promise of absolute anonymity, but on data minimization: verifying the outcome does not require Pyjam to publish its social or geographic context.
Wallets, digital signatures, and public blockchains all existed before PJM. What makes the PJM architecture original?
An applied architecture does not have to reinvent every component. What matters is how established technologies are brought together around a specific user action and which rules ensure a reliable outcome.
A conventional virtual gift may exist only as an entry in a platform’s internal database. The user sees it in the interface but cannot independently verify the movement of digital units. A public-blockchain transfer, by contrast, is verifiable, but the network itself does not know whether the viewer was supporting a creator, paying for a feature, or performing some other action.
In PJM, the internal payment intent preserves the meaning of the viewer’s action, while the memo and txid connect that intent to the public transaction. The user gets a simple interaction within the live stream, while the transfer remains verifiable through Solana data. I see this connection between product context and on-chain outcome as the model’s key differentiator.
Which parts of the system did you personally define, and which were handled by the development team?
I developed the PJM concept and the digital-rewards model for Pyjam. At the architectural level, I defined the roles of the sender, recipient, and platform; the rules for selecting a payment route; the sequence of states; the safeguards against duplicate processing; and the conditions under which a transaction could be considered complete.
I also selected the direction of the Solana integration and established the interaction rules for the interface, server, embedded wallet, relay, and blockchain. This required determining which data should pass between those layers, where each validation should take place, and which result would justify a change to Pyjam’s internal state.
The developers implemented the individual components in code. I was responsible for the architectural requirements, the division of responsibilities among those components, and the coordination of the end-to-end payment process.
You have published articles, received industry awards, and served as a judge for technology awards. How does that professional experience influence your work?
I see those as different forms of professional practice. Publishing allows me to systematize architectural decisions and explain in detail why a system was designed in a particular way. In my work on PJM, for example, I have examined the integration of a wallet into a streaming application, transaction signing, fees, and the connection between a digital unit and the logic of a live broadcast. It is important to me to share knowledge with the professional community, discuss architectural decisions, and contribute to the development of technology.
Awards provide external validation of a project, while serving on a judging panel requires me to assess the work of other professionals. That process involves distinguishing delivered results from claims, understanding an individual’s contribution, and evaluating the soundness of the architecture, the quality of execution, and the practical value.
This experience also shapes how I present PJM. I draw a clear line between the underlying technologies and my own architectural contribution. Wallets, digital signatures, and Solana already existed. My work lies in designing the rules and connections that turn them into a coherent live-streaming experience.
Where else could the principles behind this architecture be applied?
PJM’s specific interfaces and rules are designed for Pyjam, but the underlying model has broader applications. It could be used for digital gifts, pooled fundraising, payments for in-app features, and other scenarios in which an internal user action needs to be linked to a public transaction.
The general principle is to connect an action within a product to a final on-chain result, protect the transaction from duplicate processing, and avoid forcing the user to understand the blockchain’s technical parameters.
This is a description of where the approach could be applied, not a claim that other platforms have already implemented PJM. To me, a mature blockchain integration is one that hides operational complexity from the user while preserving proof of the outcome. During a live stream, the user should only need to confirm a clear action and see a reliable status. Once the process is complete, there should be a record that can be independently verified, rather than simply taken on trust.
