Rahman_crypt

we spent a decade teaching people to never share their seed phrase. now the default way to let an ai agent pay for things is to hand it a private key. that feels backwards to me. an agent with a key can sign anything. the only thing between it and your money is its instructions, and instructions are the easiest thing to tamper with. a webpage can slip it new ones. so can a tool result. the key doesn't know who's asking, it just signs. so the fix can't live in the prompt. it has to live somewhere the agent can't talk its way past. that's the idea behind @spactvault, which i built at #NEARHackathon. how it works your money sits in a vault contract on @NEARProtocol. you set the rules. the agent never gets your key. it gets a NEAR function-call key that can do one kind of thing: ask the vault to pay. then the contract decides, on chain: - small payments go through on their own - bigger ones wait until you approve that exact payment in your NEAR wallet - anything over the cap, or to someone not on your allowlist, is refused, and no approval can push it through the agent can't move tokens itself, can't change the rules and can't approve its own request. if it gets prompt-injected, the worst it can do is spend inside the limits you set, to people you already allowed. NEAR makes this unusually clean. function-call keys are part of the account model, so "this key can only call these methods on this contract" is enforced by the protocol, not by my code promising to behave. and the vault has no access keys at all, so nobody can swap its code out, me included. the part i didn't expect to matter the hard part wasn't the contract. it was the approval screen. when you approve a payment, you're trusting that what you see is what you sign. if the website, or whoever runs it, lies about the amount or the recipient, a normal approve button is useless. so every request gets a fingerprint: a hash of its exact terms, stored by the vault. the approval page recomputes it in your browser, and the vault only accepts an approval that matches. change one character of the terms and it refuses. you're approving the terms, not the ui. i learned this the practical way too. in my first real run i clicked through what i thought was the approval, and it was actually step one, registering a deposit address. the page now says "step 1 of 2" in plain words. small thing, but it feels like a lot of crypto losses happen at exactly this moment: a person clicking yes without knowing what yes means. cross-chain agents don't only want to pay people on NEAR, so the vault can also pay out on other chains through NEAR Intents. those payments always wait for you, whatever the amount, because once the tokens leave, the vault can't see what happens on the other side. i'd rather the contract be honest about where its guarantees end. what actually happened on mainnet real USDC, nothing staged: - the agent asked for 1 USDC to my address on Base - the vault held it and i got a review link - i approved in my NEAR wallet - 0.997398 USDC landed on Base in under 40 seconds - then the agent asked for 5 USDC. over the cap, refused on chain (HARD_CAP_EXCEEDED), nothing moved every transaction is linked in the repo. how i tested it i wrote down every attack i could think of (a lying backend, a prompt-injected agent, replayed approvals, parallel requests racing each other) and turned each one into a test. 18 cases run on every commit, 17 of them against a real NEAR node, and the results are public on the site. it's still an unaudited prototype, so small amounts only. but the shape feels right to me: agents get budgets, humans keep keys, and the rules live where nobody can argue with them. try it: spactvault.xyz code: github.com/0xileri/SpactVaul… genuinely curious: if you ran an agent you didn't write yourself, what would its default limit be? and would you set it per payment, per day, or per recipient? @NearLegion @NearBuilders