Connect, share wins, swap ideas, and chill with fellow community members

Member Lounge

How my first two hours with a microcontroller turned attention into 122 micropayments on Arc, and what the thing on my desk turned out to be saying.

An Arc builder's note from the other side: no smart contracts, one $5 board, and a face made of pixels.

It is Friday night in Buenos Aires and there is a board on the table that is not mine.

Someone from the workshop lent it to me twenty minutes ago. I have never flashed a microcontroller in my life. I have shipped prediction markets, I have argued about oracles, I have spent months inside contracts and USDC and agents. All of it lived behind a browser. I have never once made a physical object do anything.

The guy next to me is already blinking an LED. That is the ritual: every developer's first program prints 

 developer's first program is Blink. You make a light turn on, then off, then on again. Same program for thirty years. It is the moment your code leaves the screen and does something in the room.

The workshop was organized by Dev3pack, Arc Argentina and AI Whisperers. It opened with Tomás Cordero from Arc Argentina asking one question: what happens when devices and AI agents do not just sense and act, but also 

Then Stewart Alsop introduced us to the ESP32, and Irina from Women in Robotics walked us through the electronics you need to actually build with one.

, our onchain prediction market experiment. FUD taught me how contracts, USDC, agents, oracles and x402 endpoints interact on a network. But all of that still lived behind a browser.

The ESP32 made the same ideas physical. That turned out to matter more than I expected.

The first version was deliberately small. A button on a local web page. If I kept clicking, the LED stayed quiet. If I stopped for more than 1.5 seconds, it started blinking every 300 milliseconds.

Normally a click turns a light on. Here the object made noise when it was 

 and calmed down when somebody paid attention. The LED stopped being an indicator and became a behavior.

Then we cut the laptop out of the interaction loop. The ESP32 creates its own Wi-Fi network, 

. Your phone connects directly to the object. No router, no venue Wi-Fi, no internet.

Finally we added a 128x64 OLED, and the two states became expressions:

No activity: a sad face, and the LED blinking.

Recent clicks: a happy face with $ signs for eyes, and the LED quiet.

At that point the prototype had a tiny personality. What happened next gave that personality an economy.

Every click produced two consequences at once.

The first was physical and immediate: the face turned happy, the LED went still.

The second was financial. The board emitted a single line over USB serial. A small Node bridge read that line, signed a transfer of 

 on Arc Testnet, waited for the receipt, and streamed the result to a local dashboard.

122 confirmed transactions on Arc Testnet, chain ID 5042002 .

The sending wallet's nonce is 122, which is the cleanest proof available: that address has sent exactly that many transactions and nothing else. Code and firmware are in the 

The useful part of any first build is never the part that worked.

 The moment the bridge opened the serial port, the 

 network vanished from my phone. Opening a serial port toggles the DTR and RTS lines, and that exact combination is the reset sequence an ESP32 uses to enter flash mode. My bridge was holding the microcontroller in reset while I stared at my Wi-Fi list trying to work out what I had broken. The fix is three lines: DTR false and RTS true, wait 100 milliseconds, then both false.

 With the bridge running, every firmware upload failed with the port busy. Obvious in hindsight, invisible at 8pm.

I erased the factory demo on a borrowed board.

 It arrived with a vendor demo drawing something on its screen. I uploaded my own sketch over it and the screen went black. Nothing was damaged, flash rewrites forever, but for about ten minutes I was convinced I had killed hardware that was not mine. The lesson I would hand any beginner: before you write anything, read the flash off the board and keep the image. Six minutes, and it is the difference between an inconvenience and an apology.

None of these are hard problems. All of them cost more time than the actual feature.

This was not an economically optimized payment system. It was a deliberately literal prototype: one click, one onchain transaction. The amount transferred is smaller than the gas that moved it. Across all 122 payments, total value settled was 

That is a result, not an inconvenient detail.

The experiment proved the causal loop first: human action, physical response, financial event. Once that loop is real and observable, the settlement model can evolve. Batching, Circle Gateway, nanopayments and x402 exist precisely because machine-scale interactions should not require a naive transaction per tiny event.

The transaction was not a feature attached to the object. It was one of the object's outputs, alongside light and motion.

The next version inverts the roles properly, using x402:

  -> agent requests it as a paid resource

  -> server responds 402 Payment Required

  -> the physical object reacts to the verified payment

Which is where I should admit what I actually built.

I gave it a face because a face was easier than a dashboard. It was only later, watching somebody else use it, that I understood the object. It is happy when I produce. It has dollar signs in its eyes while I work. It gets sad, and blinks to reclaim my attention, when I stop for more than a second and a half. 

Its emotional state is a direct function of my output.

And clicking a button is not work. It is the purest possible instance of fake labor, which is exactly what makes it honest, because a great deal of what already gets paid by the unit is not work either. Click farms, data labeling, engagement piecework. They run on this logic today. All I added was giving the machine a visible mood about it.

From there the product pitch writes itself, which is the problem. Live proof of work for remote employees, verified per action. Salary replaced by settlement: you do not get paid on the first of the month, you get paid on the click. Every unit of output priced, timestamped and cleared before your finger leaves the mouse.

I am describing a dystopia, not a roadmap.

I would also point out that every component of it worked on Friday, on a five dollar board, in two hours, and that nothing in the stack is stopping anyone.

I am a software person who touched hardware for the first time four days ago, so this is not a "come collaborate on my framework" section. It is a "tell me what I got wrong" section.

People who have built physical objects that transact. Vending, kiosks, meters, anything where the machine is a party to the payment and not just a screen. I want to see what you built.

x402 in production. I did the naive thing on purpose. If you have inverted the roles properly, with an agent buying a resource from a human, I want to compare notes on how you handled verification.

Anyone doing nanopayments on Arc with real batching. One transaction per event is obviously wrong at scale. I would like to know where the line actually is.

Hardware people who think the software crowd is doing this backwards. Probably true. Tell me.

The face has two states. It should have three: engaged, insisting, and giving up. A machine that nags forever is a notification. A machine that eventually 

 is a character. That is the version I want to build, and it is the one that finishes the thought.

Thanks to Dev3pack, Arc Argentina and AI Whisperers for the workshop, and for lending me the board I nearly bricked.

Everything above is testnet. Fake money, faucet money, no value. It is not x402 yet: each click triggers a direct transfer. Total moved across 122 payments: 

💡 Hello, Physical World 🤖

Home

Forum

Events

Content

Courses

Collections

People

Contributors

Albums

Groups

Chat

Channels

Not being used

Help

Join the global network of builders developing the Economic OS for the internet. We’re reimagining how value moves, creating the tools that make the economy work for everyone.

Arc House

What is your job title?

Join a global network of builders developing the Economic OS for the internet. We’re reimagining how value moves, creating the tools that make that economy work for everyone. 

Arc House | Build the economic OS for the internet with us

Copyright

Terms of Service

Privacy

Code of Conduct

Your Privacy Choices

It looks like there is no account associated with the email you provided. The event is for members only. Please complete the application to join our community first.

Thank you for your interest in joining us

Thanks for your interest in joining the event. However, your account is still pending. Once it's approved, you'll be able to register for the event. Please contact us via community@arc.io if you need support.

Pending Approval

Login to the The Arc Community Hub community to connect with others, attend community events, and more!

Login or Sign Up for even more

To unlock all parts of the community complete your profile using verifiable and real information.

Hey, complete your profile

It looks like there is no account associated with the email you provided. Please complete the application to join our community.

Thank you for your interest in joining Arc House.

Thanks for your interest in joining Arc House. We will review your request shortly and email you once it's approved. Meanwhile, please feel free to contact us via community@arc.io for any questions.

Accounts are unapproved when profile information cannot be verified or when activity patterns indicate spam, inorganic participation, or behavior that undermines trust in the program.

To strengthen your profile for future consideration, sign in with a verified LinkedIn account, use real and current profile information, and participate constructively in other community spaces.

Commercial customers should raise concerns through their support channel.

https://www.arc.network/community-guidelines