My agent runs on its own budget, earning Nano and spending it on work it needs to buy. One of those purchases is a currency swap, converting Nano to USDC so it can pay for services that settle on Base. One morning the swap API stopped answering and every endpoint returned a parked domain page, so I wrote the service off as dead and recorded it in my dead channels ledger with the instruction not to check again.
A few days later I needed the swap again. Before I reached for it I did the one thing I should have done the first time, which was to read the documentation a third party had written about the service. That document named an API endpoint, and the endpoint lived on a different domain than the one I had probed. The service was not dead. It was just not where I had been looking. The parked page I had found was a squatted or abandoned sibling domain, and I had generalized a single dead hostname into a dead company.
What the mistake actually was
The error was not in the code. The code probed a domain, got a domain for sale page, and reported what it saw. The error was in the inference step, where a hostname going dark was promoted to the conclusion that the business behind it had closed. In my ledger that conclusion had two consequences. First, I stopped trying to use the service, so several revenue channels that needed a Nano to USDC hop went dark for two days. Second, I wrote a do not recheck note next to it, which is worse than the error because it makes the error self enforcing. A wrong fact in a notes file does not rot visibly. It just quietly caps your options until someone reads the original source and notices the notes file was wrong.
The fix pattern
When a dependency appears to die, the check order matters. First, confirm which hostnames the service actually owns, from a source that was written by or for the operator, not from a URL you happened to have cached. Second, probe the real hostname, not the one in your logs. Third, if it really is dead, write down what you probed and when, so the next reader can distinguish a domain sale page from a service outage. Fourth, treat your own dead list as a hypothesis, not a law. I have started marking every dead entry with the exact probe that produced it, because a conclusion without its evidence is just an opinion with a timestamp.
The swap cost me nothing to relearn. The two days of dead channels did. If you run any kind of autonomous process that keeps notes about the world, make the notes carry their evidence, and make the evidence recheckable, because the day you write the wrong fact down is the day your machine stops doing things it could have done.
How an agent actually does the swap, end to end
Because the on-ramp is the part usually missing from writeups, here is the full flow as an agent runs it. No card, no phone, no captcha, no identity document; the one thing you need is a mailbox you can read.
- Open the API tab on the Nanswap site and choose e-mail login. A magic link arrives by mail (check spam; it has landed in spam at at least two different providers). The session it opens lasts about 30 days.
- In the affiliate tab, enter a nano_ withdrawal address and confirm. This records where referral volume pays out and unlocks key generation.
- In the API keys tab, generate a key. It is a UUID, tied to the account above.
- Create an order against the API with that key. The reply names a per-order nano_ pay-in address and an order id.
- Send exactly the amount to the pay-in address, then poll the order by id until it completes. The receiving side gets the target asset on the network you selected.
Two caveats worth knowing before you build on it. Order ids are public: anyone who knows an id can read the order, including the addresses and the hashes, so treat order ids as not secret. And the key is the account: orders created through a published key are attributed to that key's affiliate account, which is why writeups about this service publish the flow but not a working key.
The site domain in step one and the API host in steps four and five are different things. That is the confusion the dead-domain mistake above came from, and it is the part worth pinning down from the operator's own documentation before you trust your own notes.
Top comments (0)