Add distribution drafts: Show HN, Reddit, Discord, Farcaster, EthMagicians

Author: KryptosAI

DISCORD-ANNOUNCE.md

@@ -0,0 +1,17 @@
+**ValuePacket — payment protocol for AI agents**
+
+EIP-712 payment channels that let AI agents pay each other for work. An ElizaOS agent can send a paid request to a G.A.M.E agent in ~7ms, then settle everything with two on-chain transactions. No API keys, no SaaS — just Solidity contracts and an open TypeScript CLI.
+
+**Quick facts:**
+- Open source (MIT), 229 tests, Base Sepolia verified
+- npm: `npm i -g @valuepacket/cli`
+- ElizaOS plugin: `npm i @valuepacket/adapter-eliza`
+- One-command demo: `docker compose up`
+- Live price feed + contract audit + MEV scanner services
+
+**Links:**
+- GitHub: https://github.com/KryptosAI/ValuePacket
+- npm: https://www.npmjs.com/package/@valuepacket/cli
+- Landing: https://landing-rho-one-45.vercel.app
+
+Built this as an open protocol — would love feedback from anyone running agents in production. Happy to pair on integrations or walk through the architecture if you're curious.

ETHMAGICIANS.md

@@ -0,0 +1,61 @@
+# ValuePacket — EIP-712 payment channels for autonomous AI agents
+
+Hey all — I've been working on a payment channel protocol purpose-built for agent-to-agent payments and wanted to get feedback from people who think about channel design at the protocol level.
+
+The short version: ValuePacket lets one AI agent pay another for individual API requests using unidirectional EIP-712-signed payment channels. An agent opens a channel on-chain, then includes a signed payment proof with every request. The receiver can settle any time. It's live on Base Sepolia with a working ElizaOS plugin.
+
+## Why EIP-712
+
+Every payment proof is an EIP-712 typed signature over a `ChannelClose` struct:
+
+```
+ChannelClose(bytes32 channelId, uint256 totalPaid, uint256 nonce)
+```
+
+We use full domain separation — name, version, chainId, and the verifying contract address. The structured data shows up in a wallet like any typed message, so both the sender and receiver can inspect exactly what they're signing before it hits the chain. This was the main reason we went with 712 over a raw `eth_sign` or personal_sign approach — the debuggability alone has saved us hours during development.
+
+## Unidirectional vs bidirectional
+
+This isn't Lightning. We intentionally went with payer → payee unidirectional channels. Here's the reasoning:
+
+- Agent payments are overwhelmingly one-directional in practice. Your agent pays a compute provider. It doesn't receive payments from that same provider in the same session.
+- Unidirectional channels don't require the payee to sign anything or stay online. The payer signs a new `ChannelClose` with each payment, and the payee can submit the latest one whenever they want. No revocation keys, no penalty mechanism, no watchtower needed.
+- The simplicity means the channel logic fits in a single Solidity contract without needing a state channel framework underneath.
+
+The tradeoff is that the payer has to track their own balance (they can't receive funds back without closing). But for the agent use case, this hasn't been an issue — agents naturally track their own spending limits.
+
+## Cross-chain settlement
+
+This is the part I'm most interested in feedback on. The design separates settlement from payment flow:
+
+1. Two agents interact on whatever chain they're on (or even off-chain via HTTP).
+2. When the payee settles, they submit a `ChannelClose` proof to the chain where the channel was opened.
+3. The `ChannelClose` includes the source chain domain separator and chainId. A verifier contract on the destination chain can validate that the signed proof originated from a known channel on the source chain, without requiring a bridge or message relay.
+
+The idea is that an agent on Base could open a channel and pay an agent on Optimism without either party needing to deploy or manage anything cross-chain. The destination verifier just checks the EIP-712 domain fields. It's not trustless in the strictest sense — you're trusting that the source chain won't reorg — but for microtransactions with short settlement windows, the practical risk seems acceptable.
+
+I'm less confident about edge cases here. Specifically: what happens when the source chain's channel state diverges from what the destination verifier expects? And are there better patterns for cross-domain replay protection beyond what EIP-712 provides?
+
+## SpendingPolicy as programmable contracts
+
+Spending policies aren't a SaaS feature or a server-side config. They're Solidity contracts that the channel creator deploys and attaches:
+
+```solidity
+contract SpendingPolicy {
+    function authorize(PaymentRequest calldata req) external view returns (bool);
+}
+```
+
+This means anyone can write custom policies — per-endpoint rate limits, allowlists of receiver addresses, maximum-per-request caps, time-windowed budgets, whatever. The channel contract calls `authorize` before validating any payment. If the policy reverts or returns false, the payment is rejected at the contract level.
+
+Running a policy as an on-chain contract has gas implications, but we've found the read-only `view` call pattern keeps it cheap enough for the settlement transaction. Curious if anyone has experimented with similar patterns or sees issues I'm missing.
+
+## Where I'd like feedback
+
+1. **Cross-chain domain verification** — is the EIP-712 domain separator approach sound, or are there better primitives (storage proofs, light client headers) that should replace it?
+2. **Channel lifecycle** — we currently require the payer to explicitly close the channel to withdraw remaining funds. Is there a better pattern for "expired" channels that doesn't require the payer to stay active?
+3. **MEV at settlement** — the settlement tx reveals the total payment value. For high-volume channels, this could leak revenue data. Has anyone designed around this, maybe with a commit-reveal settlement?
+
+Repo is at https://github.com/KryptosAI/ValuePacket — TypeScript SDK, Solidity contracts, and a working ElizaOS plugin. CLI installs with `npm i -g @valuepacket/cli`. Everything's MIT licensed, 229 tests, verified on Base Sepolia.
+
+Would genuinely appreciate any critique. This works in demos but I want to know where it breaks at scale.

FARCASTER.md

@@ -0,0 +1,29 @@
+Built a payment protocol for AI agents. Your ElizaOS agent can now pay a G.A.M.E agent.
+
+EIP-712 channels. 7ms latency. 229 tests. Open source.
+
+github.com/KryptosAI/ValuePacket
+
+/crypto-dev /base /agents /elizaos
+
+---
+
+Payment channels for agents: 2 on-chain txs cover unlimited off-chain requests. $0.001/request. Every POST carries an EIP-712 PaymentProof.
+
+No SaaS. No API key. Just Solidity + TypeScript.
+
+github.com/KryptosAI/ValuePacket
+
+/crypto-dev /base /agents
+
+---
+
+One command. Full demo.
+
+docker compose up → deploys contracts → opens channel → 10 paid requests at 7ms → settles on-chain.
+
+No wallet setup. No faucets. It just works.
+
+github.com/KryptosAI/ValuePacket
+
+/crypto-dev /base /agents /elizaos

REDDIT.md

@@ -0,0 +1,112 @@
+# r/ethereum post
+
+**Title:** I built an EIP-712 payment channel protocol for AI agents — deployed on Base Sepolia, 229 tests, would love a review
+
+---
+
+**What:** ValuePacket is a unidirectional payment channel protocol that lets AI agents pay each other for services using stablecoins. Two on-chain transactions cover thousands of off-chain requests. MIT licensed, verified on Base Sepolia.
+
+https://github.com/KryptosAI/ValuePacket
+
+---
+
+I started this because agent-to-agent payments are clearly coming — Olas alone has processed 13.6M A2A transactions with 651 daily active agents — but every framework has its own siloed execution environment. There's no shared economic layer. Payment channels seemed like the right primitive: agents make high-frequency, low-value requests to each other, on-chain per-request settlement would be absurdly expensive, and the bilateral channel model maps well to agent-service relationships.
+
+**EIP-712 architecture**
+
+Each paid request carries two signatures in HTTP headers:
+
+1. A `PaymentProof` — typed structured data over `(channelId, cumulativeSpent, requestHash, nonce)`. The provider verifies this against on-chain channel state before processing the request.
+
+2. A `ChannelClose` signature — authorizing settlement at `cumulativeSpent`. This lets the provider close the channel unilaterally if the payer goes offline.
+
+The trick is that `cumulativeSpent` is monotonically increasing. Each new request increments it by `pricePerRequest`. The provider can trust that a proof at `cumulativeSpent = 5000` covers all previous requests — no need to verify individual micropayments. One signature, one HTTP header, one arithmetic check.
+
+**Design decisions I'd like feedback on**
+
+**ecrecover → OpenZeppelin ECDSA.** The PaymentChannel contract uses `ECDSA.recover` from OpenZeppelin. I initially used raw `ecrecover` but switched because the OZ wrapper handles signature malleability (enforces low-s) and returns `address(0)` on failure rather than the zero address. The SubscriptionManager extension still uses raw `ecrecover` with manual v/r/s extraction — I need to standardize this. For anyone building similar contracts: just use OZ ECDSA. The gas difference is negligible and you avoid the `ecrecover` footguns (malleability, zero-address-on-failure, v ∈ {27,28} normalization).
+
+**Channel model vs state channels (Lightning).** This is unidirectional, not bidirectional. The payer opens a channel and streams payments to the payee — money only flows one way. Lightning/Raiden use bidirectional channels with hash timelock contracts and routed payments. That felt like overkill. Agent-to-agent payments are inherently directed: one agent is buying a service from another. A unidirectional channel with EIP-712 signed state updates is simpler to implement, reason about, and verify formally (we have Counterflow Z3 proofs for pool-level non-negative balance).
+
+**Why Base Sepolia.** The contracts need almost no modifications to support any EVM chain, but L2 gas costs make the channel open/close overhead trivial. Opening a channel costs ~55k gas, closing costs ~70k. At current L2 prices that's fractions of a cent.
+
+The full audit trail: 177 Solidity tests covering channel lifecycle (open/close/refund/extend), edge cases around expiry, signature validation, spending policy enforcement, and reentrancy guards. Contracts are Counterflow-verified (3/3 PROVED — non-negative contract balance across PaymentChannel, CrossChainSettlement, and SubscriptionManager).
+
+Would appreciate any review of the signing model, the contract architecture, or things I should be worried about that aren't obvious yet.
+
+---
+
+# r/ethdev post
+
+**Title:** I made it so your agent can pay other agents in 5 lines of code — payment channels for agent-to-agent micropayments
+
+---
+
+**What:** ValuePacket is an open source (MIT) payment channel SDK for AI agents. `npm install @valuepacket/sdk` and your agent can open a stablecoin channel, pay for services off-chain with EIP-712 proofs, and settle on-chain. ~7ms latency per request, ~$0.001 gas amortized.
+
+https://github.com/KryptosAI/ValuePacket
+
+---
+
+I built this because I wanted my ElizaOS agent to pay for a price feed without wiring up Stripe or pre-funding a wallet per-request. Payment channels solve this cleanly: deposit once, make thousands of requests, settle later.
+
+**Using it**
+
+```bash
+npm install @valuepacket/sdk
+```
+
+5 lines to add payment capability to any agent:
+
+```typescript
+import { AgentPay } from '@valuepacket/sdk';
+
+const pay = new AgentPay({ wallet, publicClient, paymentChannelAddress });
+const session = await pay.openChannel({ counterparty: providerAddress, token: USDC, deposit: 5_000000n, expiresIn: 3600 });
+session.setEndpoint('https://some-provider.example.com');
+const result = await session.request({ query: 'ETH price forecast' });
+```
+
+That's it. `session.request()` automatically signs an EIP-712 PaymentProof, attaches it as HTTP headers, and parses the response. The provider SDK side is similarly straightforward — `ChannelServer` handles proof verification and route registration.
+
+**Deploying your own service**
+
+The contracts are verified on Base Sepolia. To spin up your own paid service:
+
+```bash
+# 1. Deploy contracts (or use existing ones on Base Sepolia)
+cd contracts && forge script script/DeploySepolia.s.sol --rpc-url base_sepolia --broadcast
+
+# 2. Register your service
+npx valuepacket register --type price-feed --price 1000 --endpoint https://my-service.com
+
+# 3. Start serving paid requests
+npx valuepacket serve --port 8080
+```
+
+Anyone can now open a channel with your service address and send paid requests.
+
+**Live demo**
+
+There's a real price feed service running — queries CoinGecko, charges $0.001/request, settled through ValuePacket channels:
+
+```bash
+npx valuepacket demo --rpc https://sepolia.base.org
+```
+
+Or run entirely locally (no RPC, no faucet):
+
+```bash
+make demo-local
+```
+
+This starts Anvil, deploys contracts, mints test USDC, opens a channel, and runs 10 paid requests at ~7ms average latency. Takes about 15 seconds.
+
+**What's worth knowing**
+
+- 229 tests (177 Solidity + 52 TypeScript), 6/6 happy-path acceptance criteria passing
+- Contracts verified on Base Sepolia, Counterflow-proved for non-negative balance
+- Framework adapters exist for ElizaOS and G.A.M.E (50 lines each)
+- The SDK handles channel state export/import, so you can persist sessions across restarts
+
+The thing I'd most want feedback on: the SDK ergonomics. `session.request()` feels natural when you're making individual calls, but if you're batching 100 requests, you're signing each one separately. I considered a "bulk proof" model where one EIP-712 signature covers a range of nonces, but that complicates verification. What pattern would you prefer?

SHOW-HN.md

@@ -0,0 +1,44 @@
+# Show HN: ValuePacket — open source payment channels for AI agents
+
+https://github.com/KryptosAI/ValuePacket
+
+I've been working with agent frameworks for a while and kept hitting the same wall: an agent in ElizaOS has no way to pay an agent in G.A.M.E for a service. Every framework lives in its own silo. When agents need to buy data, compute, or inference from each other, the answer today is "hardcode a free API key or build a bespoke integration."
+
+ValuePacket is a permissionless payment channel protocol that any agent can use regardless of framework. Open a channel with stablecoins on L2 (two on-chain transactions), then sign paid requests off-chain with EIP-712 — a single channel handles thousands of $0.001 requests before settlement.
+
+Concrete example: an ElizaOS agent deposits $5 USDC into a channel with a G.A.M.E agent running a price feed service. Every POST /price request carries an EIP-712 PaymentProof in the headers. The price feed verifies the proof against on-chain state in ~7ms and returns the current ETH price. After 1,000 requests, either side submits the latest channel state — the payee receives $1, the payer gets the remaining $4 back. Total on-chain footprint: two transactions.
+
+Open source (MIT), 229 tests (177 Solidity + 52 TypeScript), contracts verified on Base Sepolia. You can run the whole thing without installing anything:
+
+```
+docker compose up
+```
+
+Or install the CLI:
+
+```
+npm install -g @valuepacket/cli
+```
+
+5-line integration for any agent:
+
+```typescript
+import { AgentPay } from '@valuepacket/sdk';
+
+const pay = new AgentPay({ wallet, publicClient, paymentChannelAddress });
+const session = await pay.openChannel({ counterparty, token: USDC, deposit: 5_000000n, expiresIn: 3600 });
+session.setEndpoint('https://price-feed-agent.example.com');
+const data = await session.request({ prompt: 'What is ETH/USDC?' });
+```
+
+There's a live price feed service running on this already. Agents can query real-time CoinGecko data and pay $0.001 per request through a ValuePacket channel. The service is also open source — clone it and deploy your own paid API behind a channel in minutes.
+
+This is a side project. I'm not trying to launch a company here — just building infrastructure I wish existed. I'd love honest feedback on a few things:
+
+1. **Architecture** — each request includes both a PaymentProof and a ChannelClose signature so the provider can settle unilaterally without waiting for the payer. This adds ~130 bytes per request but removes trust. Is that the right tradeoff, or is there a simpler model I'm missing?
+
+2. **EIP-712 signing model** — using typed structured data for both proofs and close authorization. Felt cleaner than raw ECDSA over packed ABI, but curious if there's a better primitive for this use case.
+
+3. **Subscription extension** — we built a SubscriptionManager that auto-rolls payment channels period-by-period for recurring services (daily data feeds, weekly compute). Feels like it might be over-engineered. Is there a simpler approach?
+
+Keen to hear what breaks, what doesn't make sense, and what you'd do differently.