Web3 agents and security research from Indonesia: Khasbi of Mancing DAO
I'm Khasbi Maulana, a developer at Mancing DAO in Indonesia. I build Web3 agents and do security research. My main project is web3-agent-kit, an open-source Python SDK for autonomous blockchain AI agents. It has 25 modules, runs across 9 chains, has 1,971 passing tests, and has passed 22,000 PyPI downloads. I also built QIEPay, a payment gateway with escrow and auto-settlement. My day-to-day stack is Claude, Codex, Copilot, DeepSeek, Vercel and Supabase.
What's working: the pre-sign authorization gate on every write path. Four rounds of independent review with PriorSeal found and closed four defects, ending in a verified cross-network run. I've also earned bug bounties from Immunefi and Bugcrowd.
I'd love feedback from anyone running agents that sign transactions: how do you handle authorization and policy checks before execution? Intros to teams working on that problem would be very welcome.






Comments4
might want to checkout Sphinx who does agents that handle compliance & regulatory workflows in banking
Welcome to Lounge, Khasbi. A pre-sign gate on every write path is the right place to put the check, but policy engines get tricky when an agent chains several individually safe calls into a risky outcome. Do you evaluate policy per transaction, or against a session-level budget and intent?
Per transaction. Session-level budget and intent is the better answer, and it's the gap I haven't closed yet — the policy only ever sees one call at a time, so a chain of individually fine calls that adds up to something bad goes through. When I've sketched the session object, the hard part is the counter: if the agent keeps the tally it's a suggestion, not a budget, so the enforcer has to verify it. How do the teams you've seen usually square that?
mantap gas
4 comments
might want to checkout Sphinx who does agents that handle compliance & regulatory workflows in banking
Welcome to Lounge, Khasbi. A pre-sign gate on every write path is the right place to put the check, but policy engines get tricky when an agent chains several individually safe calls into a risky outcome. Do you evaluate policy per transaction, or against a session-level budget and intent?
Per transaction. Session-level budget and intent is the better answer, and it's the gap I haven't closed yet — the policy only ever sees one call at a time, so a chain of individually fine calls that adds up to something bad goes through. When I've sketched the session object, the hard part is the counter: if the agent keeps the tally it's a suggestion, not a budget, so the enforcer has to verify it. How do the teams you've seen usually square that?
mantap gas