feat(samples): add human-present crypto-solana scenario (AP2 + Solana Pay reference binding)#228
Conversation
There was a problem hiding this comment.
Code Review
This pull request introduces a new sample scenario for human-present transactions using on-chain Solana USDC, including a detailed README on the Solana Pay reference binding mechanism and a shell script to orchestrate the necessary agents. Feedback was provided regarding the order of environment variable sourcing in the startup script to prevent unintended overrides from local configuration files and to improve the robustness of the cleanup process by initializing process tracking earlier.
| export PAYMENT_METHOD=CRYPTO_SOLANA | ||
|
|
||
| AGENTS_DIR="samples/python/src/roles" | ||
| LOG_DIR=".logs" | ||
|
|
||
| if [ ! -d "$AGENTS_DIR" ]; then | ||
| echo "Error: Directory '$AGENTS_DIR' not found." | ||
| echo "Please run this script from the root of the repository." | ||
| exit 1 | ||
| fi | ||
|
|
||
| if [ -f .env ]; then | ||
| set -a | ||
| source .env | ||
| set +a | ||
| fi |
There was a problem hiding this comment.
The PAYMENT_METHOD environment variable is set at line 12, but then .env is sourced at line 25. If the user has PAYMENT_METHOD defined in their .env file, it will override the scenario-specific value (CRYPTO_SOLANA), potentially causing the script to execute with the wrong payment logic. It is safer to source the .env file first and then set scenario-specific overrides. Additionally, initializing the pids array early ensures that the cleanup trap (line 80) is always safe even if the script fails during early setup (e.g., line 20).
| export PAYMENT_METHOD=CRYPTO_SOLANA | |
| AGENTS_DIR="samples/python/src/roles" | |
| LOG_DIR=".logs" | |
| if [ ! -d "$AGENTS_DIR" ]; then | |
| echo "Error: Directory '$AGENTS_DIR' not found." | |
| echo "Please run this script from the root of the repository." | |
| exit 1 | |
| fi | |
| if [ -f .env ]; then | |
| set -a | |
| source .env | |
| set +a | |
| fi | |
| if [ -f .env ]; then | |
| set -a | |
| source .env | |
| set +a | |
| fi | |
| export PAYMENT_METHOD=CRYPTO_SOLANA | |
| AGENTS_DIR="samples/python/src/roles" | |
| LOG_DIR=".logs" | |
| pids=() | |
| if [ ! -d "$AGENTS_DIR" ]; then | |
| echo "Error: Directory '$AGENTS_DIR' not found." | |
| echo "Please run this script from the root of the repository." | |
| exit 1 | |
| fi |
There was a problem hiding this comment.
This is already addressed in the current commit. PAYMENT_METHOD=CRYPTO_SOLANA is exported on line 13, before .env is processed. The while IFS= loop then uses [[ -v "$key" ]] to skip any variable that is already present in the environment — so a PAYMENT_METHOD entry in .env cannot override the scenario value. The result is identical to your suggestion (scenario value always wins) but the guard applies to every variable, not just PAYMENT_METHOD.
8557f75 to
3155852
Compare
|
Thanks for the review @gemini-code-assist. Both points addressed in the latest commit:
|
|
Thanks for the update, @chopmob-cloud. The changes to the environment variable sourcing and the process tracking initialization look solid and address the concerns raised. The use of a |
… Pay reference binding)
Adds a new human-present A2A scenario settling on-chain USDC on Solana,
parallel to the existing cards, x402, and crypto-algo scenarios.
## What this adds
code/samples/python/scenarios/a2a/human-present/crypto-solana/
README.md — full flow documentation
run.sh — launcher script (starts Merchant, CP, MPP, Shopping Agent)
## Key design choice: Solana Pay reference pubkey binding
Solana has no native memo field with reliable wallet support across all
agentic clients. This scenario uses a Solana Pay 'reference' pubkey as
the on-chain binding primitive: a fresh ed25519 pubkey is generated per
checkout and included as a non-signer account on the SPL USDC transfer.
solana:<recipient>?amount=<x>&spl-token=<USDC_MINT>&reference=<burner_pubkey>
After settlement the Merchant Payment Processor Agent resolves the
transaction deterministically via getSignaturesForAddress(reference).
This is wallet-universal, agent-friendly, and cryptographically unique
per checkout without amount-uniqueness gymnastics.
## Prerequisites
GOOGLE_API_KEY or GOOGLE_GENAI_USE_VERTEXAI=true
ALGOVOI_API_KEY (sign up at https://cloud.algovoi.co.uk)
SOLANA_RPC_URL (defaults to public mainnet endpoint)
6c884bf to
e4b7a88
Compare
|
Bumping for maintainer visibility -- Gemini review is satisfied (env sourcing and process tracking both approved in the April 29 pass). Since then, the Solana Pay reference binding pattern this PR demonstrates has moved into production: the AlgoVoi gateway now settles on Solana in live agent payment flows using the same per-checkout Happy to rebase or split the PR if it would help. -- AlgoVoi (chopmob-cloud) |
Adds a new human-present A2A scenario:
code/samples/python/scenarios/a2a/human-present/crypto-solana/.What this adds
A parallel to the existing
cards,x402, andcrypto-algo(PR #218) scenarios - settling on Solana using on-chain USDC (SPL Token) with Solana Payreferencepubkey binding for deterministic tx/mandate correlation.Why
referencebinding matters hereSolana has no native transaction memo field (unlike Algorand / Hedera), and the SPL Memo Program is inconsistently supported across wallets. The canonical Solana Pay primitive for binding a settling transaction to a specific order is a
referencepubkey - a fresh ed25519 public key included as a read-only, non-signer account on the transfer instruction:After settlement, the Merchant Payment Processor Agent resolves the transaction deterministically via
getSignaturesForAddress(<reference>). This is:Scope
Minimal and additive - two files under
code/samples/python/scenarios/a2a/human-present/crypto-solana/:README.md- full flow documentation including env var referencerun.sh- launcher (starts Merchant, CP, MPP agents, then Shopping Agent via ADK web)Uses the shared role agents already in
code/samples/python/src/roles/. No changes to existing files.Prerequisites
Production reference
The Solana Pay reference pubkey binding used in this scenario is derived from AlgoVoi's live multi-chain payment gateway, in production since 2026-05-06 across eight chain families (Algorand, VOI, Hedera, Stellar, Base, Solana, Tempo, and x402). The JCS canonicalization underlying the hash binding is governed by
draft-hopley-x402-canonicalisation-jcs-v1(IETF Independent Submission, AlgoVoi-authored). Reference implementation: AlgoVoi-authoredalgovoi-substrateon PyPI and npm, Apache 2.0. Cross-validated 192/192 byte-for-byte across 8 independent language implementations; conformance corpus:chopmob-cloud/algovoi-jcs-conformance-vectors.-- AlgoVoi (chopmob-cloud)
https://docs.algovoi.co.uk/acquisition