This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.
The setup
Brickwarden has two agents.
One builds a tokenized asset on Ethereum Sepolia.
The other watches it and can freeze or burn tokens on its own if something looks wrong. Every other piece worked, tokenize, launch, whitelist, mint, all three of Warden's compliance triggers.
The last piece was dividends, and it turned into a two week standoff with one API call.
The bug that wasn't a bug
Paying out dividends meant approving a stablecoin allowance first, so the contract could pull funds from the wallet.
The docs gave a clean example payload. I matched it exactly.
It came back with:
"messages": "Tokenizer address is required if token symbol is one of BKN/USDT/USDC"
Fine, add the field. Retried.
"messages": "User not found"
Same wallet. Same address that had signed every other successful call in the project, tokenize, whitelist, mint, all proven on chain.
Tried the field as an email instead of an address. Different error.
Tried both fields together. A third, completely different error:
"messages": "client-signed prepare must return exactly one txId"
Three fields, three combinations, three unrelated failures.
At that point it stopped looking like something I was getting wrong and started looking like something broken on the other end.
Ruling myself out
Before saying that to anyone, I wanted to be sure.
I pulled the token's real spender address straight from Brickken's own get-tokenizer-info endpoint instead of guessing it. I matched their documented example field for field. Same wallet, same escrow address, same shape as their own docs.
Still "User not found."
That was the point I wrote up the exact payload and the three error messages and sent it to Brickken's support, instead of trying a fourth combination and hoping.
The resolution
A few days later, Davide and the Brickken team confirmed it: a backend bug in the approve flow for shared payment tokens, fixed and deployed to sandbox. Same code, same payload I had already tried and matched to their docs, ran clean the moment their fix landed.
Approve result:
{
"success": true,
...
}
Dividend distribution went through right after.
What stuck with me
The instinct when an API call fails three different ways is to assume you are missing something, and usually you are. But when the exact same wallet, the exact same shape, matching the vendor's own example, produces three unrelated errors across three attempts, that pattern itself is a signal worth trusting. Chasing a fourth field name would have wasted more time than writing up what actually happened and asking.
Sometimes the fix is not in your code at all, and knowing when to stop debugging and start asking is its own skill.
Repo: https://github.com/sirmos/Brickwarden
Thank you for reading!!!
Top comments (0)