Topic starter
24/10/2026 8:50 pm
TL;DR: Runtime transaction risk can persist in Midas even with more than 75 policy rules and 100+ recipients, according to Blockaid. Delegated execution needs signing-time validation and ecosystem monitoring, or approved actions can still carry hidden threat conditions.
Editorial analysis by NHI Mgmt Group, based on content published by Blockaid: “Inside the Midas Tokenization Engine: Live Security for Strategy Execution with Blockaid”.
By the numbers:
- Blockaid's Cosigner now secures 100% of Midas contracts, indicating full contract coverage for signing-time validation.
- Fordefi's setup included more than 75 policy rules, over 100 recipients, and more than 200 approved assets.
Key questions
Q: Why do approved onchain transactions still create security risk?
A: Because approval checks are static, while transaction risk is dynamic.
Q: How can security teams tell whether transaction governance is working?
A: Look for two signals: unsafe actions being blocked before signature, and benign actions passing with minimal manual review.
Q: What breaks when allowlists are the only control for onchain transactions?
A: Allowlists prove that a transaction matches pre-set permissions, but they do not prove the transaction is safe at runtime.
Practitioner guidance
- Implement signing-time transaction simulation Validate every high-risk onchain transaction at the moment of signing so the system evaluates what the action will actually do, not just who approved it.
- Separate policy enforcement from threat detection Keep allowlists and role rules, but add a second control that inspects transaction behaviour, counterparties, and decoded simulation results.
- Continuously monitor ecosystem dependencies Track the DeFi protocols, assets, and counterparties that a strategy touches so protocol exploits or depegs are detected before they cascade into losses.
Bottom line: Policy-based allowlists reduce obvious misuse, but they do not prove that an approved onchain transaction is safe at runtime.
Glossary terms: Multi-Party Computation Workspace, Transaction Simulation, On-Chain Monitoring, Delegated Strategy Manager
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 6 days ago by NHI Mgmt Group
25/10/2026 11:13 am
Transaction governance for onchain finance is now a runtime discipline, not a policy exercise. Static allowlists can reduce obvious misuse, but they cannot determine whether an approved transaction is safe at the moment of signing. In environments where value moves through MPC workspaces, the decisive control is runtime validation of intent, destination, and counterparty. Practitioners should treat transaction governance as a live control plane, not a spreadsheet of permissions.
A question worth separating out:
Q: Who should own incident response when an onchain exploit alert fires?
A: Ownership should sit with the security or operations function that can confirm whether the alert reflects a real threat, then coordinate with strategy managers and technical responders. In delegated investment environments, the practical model is shared accountability, but the response trigger must be explicit and tied to security evidence.
👉 Read our full editorial: Midas shows policy-only controls miss runtime transaction risk
This post was modified 6 days ago by NHI Mgmt Group