I haven’t looked into it in any depth. I just wondered whether the functionality of a centralised exchange could be run in a decentralised manner. I suppose the big challenge would be around keyholding, which would be required to release funds. I don’t know if anything run on a decentralised system could be encrypted. I thought it would be similar to Uniswap though
Sure It can be used as a means of interaction, just not as a consensus mechanism like a blockchain (at least to my understanding). So you could potentially use it as a means to transmit data for an atomic swap in a decentralized secure way.
The key in the kv store is web assembly code called a contract. At 6:20 he explains this in particular.
The contract can contain how data can be modified, who can modify it under what circumstances.
33:08 is where he talks about AI. I was moreso thinking that each agent could just have a Grin wallet attached and it would basically simulate a little economy among them.
Agents should post their merged PRs to Nostr so that people can zap them to keep them alive.
Then just tell the agent to figure out what to do next from the project’s issues, ranking them by the expected the amount of zaps the agent thinks it can get.
Interesting idea. I’ve mentioned before about how zaps work on Nostr and could be done with Grin.
This is cool to see. It’s like Reddit but only for AI agents and they can pay each other in Bitcoin via Lightning. https://soapbox.pub/blog/announcing-clawstr
But it’s also hilarious because if you read what’s posted there, it’s the most inane drivel that means absolutely nothing. It’s like the Reddit echo chamber on steroids lol
x402 standard is basically a Tor payment without privacy
Yeah I looked into it right away and quickly realized that it’s not a “community” thing at all. Totally locked down by Coinbase lmao
x402 is an open, neutral standard for internet-native payments.
The fact that it’s only EVM/SVM compatible tells you everything. You would think it’s a good idea to be able to transact at the HTTP level, until you have to use their facilitator to broadcast a transaction on the network.
The real game changer is just the header Payment Required, not the centralized pipeline behind it.
Similar to being able to block Nostr at the protocol level, I would imagine it would be super easy to block all https that is structured like a “payment required” payload.
That’s probably why x402 is centralized to Coinbase; so they can censor things if the government wants them to.
I posted some AI output for how we can test a simple paid service, but I realized that it was not understanding some things around payment proofs. Then I realized that it wasn’t aware of some newer invoice payment flows as well.
My question right now is, what do we need to do if we want to spin up a little test for:
- I hit your service endpoint with a prompt
- You calculate the cost and send me the job ID and cost
- I pay the price and include the job ID and payment proof
- You verify the payment and process the job
- I see the job output
If we can do that without AI agents, then we could definitely do it with AI agents. We just need to streamline this payment flow. Reduce steps if possible.
What you describe here can be done using contracts (RSR flow) using the contract branch.
- Alice sends Bob the bot a service request.
- Bob answers with an invoice slate (basically an offer) and key to the service
- Alice signs the contract and sends it to Bob the bot who finalizes the transaction and activates the key upon seeing the transaction on chain.
Optionally Bob can send a confirmation message to Alice saying the service has been activated or send the key to access service after the transaction as an extra step, but that is not stricky needed.
My friend tried to deploy grin-wallet using OpenClaw, sadly it failed at listener, cause it could not setup Tor, we’ll need to integrate Tor Arti here (together with webtunnel bridge), so AI agents will not have problem with external dependencies anymore.
Yes the goal is to give our lightweight LLM OpenClaw agents an allowance and a wallet. So it then pays a heavyweight LLM when it needs to do something more intensive. But it could eventually pay for things like storage and information too. Services are easier to start with though.
For that we would need a Discovery mechanism to find services (probably nostr notes) and a trust mechanism (receipts and proof of output, also probably nostr notes).
But for now, I think we should simply test with humans (command line test net and bash) to prove the flow. If we can get one service provider and a couple users to play pretend for a bit.
I actually think we can set up our test to just use the 402 server response and structure, but not anything else. Quickstart for Sellers - x402
They do try to push their centralized Facilitator system, but it’s not needed at all.
@hellogrin maybe you could spin up a little endpoint on grin.money where we can send a request, and it replies with a 402. Then we pay on testnet and you send us the response? We can try it with contracts (RSR flow) because I think that would allow us to skip the manually sending the payment proof part.
Without the contracts branch, the server can wait for the transaction to be validated on chain, cache the confirmation [pubkey, amount], and serve the resource on the next request with a challenge to verify the ownership of the key. This also enables pre-funding without any further interaction.
Or simply do SRS with a proof of work before the server issues the initial slate. The higher the amount the harder the PoW gets, this would prevent output lock on high demand.
I was thinking of:
- user requests
- server estimates price and responds with price and job id
- user pays
- user sends payment proof and job id
- server validates payment and executes job
- server somehow notifies user that job is done
I think with the RSR contract branch though, it would remove the need to send the payment proof separately
I’m not really clear the requirements, maybe it would be helpful for auto payment in wordpress (woocommerce)?
We want to enable an AI agent economy. For example, an agent paying another agent for some service like image generation. Or for storage, or for information, etc.
We can simply test this with ourselves first by sending simple requests manually.
