Delegated agent payments · Nuvixes
A delegated payment layer where every mandate is bounded, revocable, and legible before money moves.
Why this exists
An agent that can buy something for you is useful. An agent with unrestricted access to your wallet is a different proposition. Manda starts in that uncomfortable space between convenience and control.
The central design decision was to make delegation visible. A human owner and an agent have different roles inside one payment identity. Amount, recipient, expiry, and revocation define what the agent is allowed to do before execution begins.
The interface had to carry those boundaries into a smart-account implementation. ERC-4337 accounts and sponsored execution support the payment paths, while the public evidence page connects the experience to testnet receipts. A reassuring screen is only useful when the implementation honours its promise.
The September build work refined owner approval thresholds and documented renewed mandates and Arbitrum revocation. These details matter because authority changes over time. A mandate that worked yesterday should not quietly remain valid after its owner changes their mind.
Build journal
Recorded milestones from the build. Dates describe these events, not the entire project history.
The repository records work on precise owner approval thresholds and selecting unused onchain mandate entities.
Build documentation recorded renewed dual-chain mandates and Arbitrum revocation.
Where it stands
A published testnet prototype with documented smart-account payment paths on Arbitrum Sepolia and Robinhood. It uses testnet funds.
The next chapter
Extend verification and refine the permission experience. Automatic routing, bridging, swaps, and production custody remain outside the published verified scope.
Based on the project implementation, public proof page, and September 26 repository history.