Why Softmax never holds your keys.

The first product decision Softmax made — before the agents, before the harness, before the brand — was that we would never be able to take your money. Every architectural choice that followed reads like a derivation of that one premise.

Read everything, write nothing without your signature.

That phrase is the whole posture in nine words. Softmax reads your inbox, your wallets, your accounting integrations. It builds proposals. It surfaces confidence scores. It drafts emails. It does not sign on your behalf, hold your keys in escrow, or buffer your funds in a Softmax-controlled wallet. If a feature would require any of that, we don't ship it.

What this rules out

• Custodial wallets. The Thirdweb embedded wallet stores its key fragment client-side. We never see it. Hardware wallets and Safes never expose the key at all.
• Multi-sig where Softmax is a signer. The simplest form of "agent autonomy" would be giving Softmax one of N signatures on your Safe so we can broadcast 1-of-2 with you asynchronously. We refuse — too easy to abuse, too hard to audit, too slippery a slope.
• Fee-buffering or float. We don't hold your USDC for a few hours to net settlement. Funds settle from customer → your wallet directly. Thirdweb is the merchant of record on the card leg; we're not in the chain of custody.
• Auto-pay. No "approve once, charge forever." Every payment is its own signed transaction. The convenience cost is real; the trust gain is bigger.

What this enables

• We can't be hacked into moving your money. The worst-case breach scenario for Softmax is bad data — embarrassing, fixable. A custodial breach is a Mt. Gox.
• You don't need to trust us. The propose / approve / sign loop means our worst-case mistake is a wrong proposal you decline. No "we noticed an unusual transaction we had to process before you could review it" emails. Ever.
• Regulators have a clean answer. We're not a money transmitter. We're not a custodian. We're an SaaS application that makes API calls to public blockchains and surfaces structured proposals.
• The same architecture works for AI agent customers. When AI agents start operating businesses themselves (year 2 territory), the “agent proposes, signer approves” pattern is identical. We don't have to refactor for trustlessness; it was the foundation.

The cost we pay

Some flows are slower than they could be. Paying ten bills means signing ten transactions (or one Safe batch). Recurring vendors can't auto-pay. The CFO who really wants “just handle it” gets “here's a queue, approve at end of day” instead. We think that's the right trade. The serious operators we're building for would rather see the queue.

How you can verify

Soft commitments are worthless in this product category. The verifications that matter:

• The action ledger is append-only and visible — every proposed, approved, and executed action is logged with who proposed (always the agent), who approved (always you), what got signed (the tx hash).
• On-chain transactions all originate from your wallet address. Anyone can verify the from-address on a block explorer.
• Supabase service-role access is restricted to a small set of admin endpoints. RLS policies enforce per-workspace isolation at the database layer too — defense in depth.

If you spot a hole in any of this — a flow that violates the posture, an architectural choice that gives us implicit custody — email legal@softmax.finance. We'll fix it.