Working trust layer: Pi Testnet, EVM test-USDC and Agentic Commerce Try SafeGate
SAFEGATE CURRENT CANONICAL PRODUCT

SafeGate verifies what happened after payment.

Pi-first. Payment-rail-neutral by design.

SafeGate verifies supported payment outcomes across Pi Testnet and EVM testnets, prevents conflicting transaction reuse, creates receipt and evidence, and unlocks wallet-bound digital delivery without processing payments or holding funds.

Controlled Pi Testnet Controlled Base Sepolia USDC Durable One-Time Consume Wallet-Bound Access Pre-Production No Mainnet Production Claim

The current SafeGate core

SafeGate's current core is deliberately narrow: inspect supported payment data, apply deterministic policy, consume the verified transaction once, verify the paying wallet, authorize protected access, and record the post-payment outcome.

Purchase request or order ↓ Expected payment policy ↓ Payment-rail or blockchain inspection ↓ Deterministic verification decision ↓ Order / product / transaction binding ↓ Durable one-time transaction consumption ↓ Replay or conflicting-use rejection ↓ Payment-sender wallet ownership challenge ↓ Wallet-bound access authorization ↓ Durable post-payment outcome record

What is already working

PiCONTROLLED_TESTNET_FLOW_COMPLETED
EVMBASE_SEPOLIA_TEST_USDC_VERIFIED
ReplayDURABLE_ONE_TIME_CONSUMPTION
StageCONTROLLED_TESTNET_PRE_PRODUCTION

EVM post-payment verification

A real controlled Base Sepolia test-USDC transaction was inspected server-side, durably consumed once, protected against replay, connected to the payment-sender wallet through message signing, and used to authorize wallet-bound private report access.

Agentic commerce layer

SafeGate shows how an AI purchase intent can be policy-checked and routed toward wallet-authorized payment. The agentic layer does not control wallets or spend autonomously; it builds on the same verified post-payment outcome model demonstrated in Pi and EVM.

Documented limitation: The original browser-generated intentId and requestId were not durably preserved across the successful wallet-browser transition. They were not invented. The final result is explicitly closed with a controlled recovery boundary.

Minimal sufficient proof

The critical merchant path remains minimal. Merkle trees, signed checkpoints, and optional future anchoring are secondary integrity mechanisms not substitutes for correct payment verification or authoritative state binding.

1. Payment verification

Was the expected transaction valid for the required network, asset, receiver, amount, and outcome?

2. Durable outcome

Was the transaction bound to the correct order and consumed exactly once?

3. Wallet-bound access

Did the payment-sender wallet prove ownership before protected access was authorized?

4. Portable integrity

Can the resulting outcome be inspected independently and checked for later modification?

SafeShelf: the working SafeGate storefront

SafeGate

The verification, one-time-consumption, wallet-binding, outcome-record, and proof architecture.

SafeShelf

The first-party controlled digital-report storefront used to exercise and display SafeGate flows.

Explicit boundaries

Selected engineering milestones

Pi Testnet payment flow

Backend-verified Pi test payment, receipt, access unlock, and merchant record.

Durable outcome storage

Database write/readback, fresh evidence identifiers, and fail-secure behavior.

Proof integrity

Canonical hashes, Merkle inclusion, signed checkpoints, and independent browser verification.

Deterministic policy

Accept, reject, or human-review decisions without autonomous wallet authority.

Rail-neutral contract

A common normalized verification contract for supported payment-rail inputs.

Controlled agent-directed purchase

Human-authorized Base Sepolia test-USDC purchase using the real post-payment verification core.

Reviewer path