Security by Design: How Pods Approaches Onchain Execution
Integrating onchain financial infrastructure introduces a new category of operational and security risks.
Many integration layers rely on intermediary smart contracts, proxy execution paths, or opaque transaction builders that make it difficult for platforms to fully understand what is being executed onchain.
For exchanges, wallets, and fintech platforms operating at scale, this creates a fundamental challenge:
How can onchain capabilities be added without increasing the system’s risk surface?
Pods is designed around a simple constraint:
Infrastructure should not introduce additional execution risk.
Instead of adding intermediary smart contracts or routing user actions through aggregation layers, Pods generates the exact transaction payload required for the user’s wallet or custody provider to execute directly against the underlying protocol.
This approach keeps the execution path transparent, minimizes additional attack surface, and allows platforms to maintain the same security controls they apply to any other transaction infrastructure.
The sections below describe the principles that guide the security design of Pods.
Threat Model
Pods is designed under the assumption that transaction infrastructure may be exposed to multiple layers of risk, including compromised frontends, malicious transaction modification, and protocol-level vulnerabilities.
The system architecture is therefore built to minimize the potential impact of these scenarios.
Key threat scenarios considered in the design include:
Transaction Payload Manipulation
An attacker could attempt to alter the transaction data between generation and execution.
Pods mitigates this risk by generating deterministic bytecode that can be inspected, simulated, and validated by the integrating platform before signing.
Transaction simulation and policy enforcement can further prevent unexpected destinations or interactions.
Unauthorized Contract Interaction
A malicious actor could attempt to redirect transactions toward unauthorized contracts.
Enterprise integrations typically mitigate this risk through allowlists enforced at the wallet or custody layer, restricting transactions to approved protocol addresses.
Pods-generated transactions remain fully compatible with these policy frameworks.
Intermediary Smart Contract Exploits
Many DeFi integrations introduce intermediary contracts that hold execution logic or assets, creating additional attack surfaces.
Pods avoids this risk by not introducing intermediary smart contracts into the execution path.
Transactions interact directly with the destination protocol.
Protocol-Level Vulnerabilities
Like any system interacting with DeFi protocols, Pods integrations ultimately depend on the security of the underlying protocol contracts.
For this reason, integrations should follow standard risk management practices such as protocol vetting, contract allowlisting, and transaction simulation.
No Additional Smart Contract Risk
Pods does not introduce new smart contracts into the execution path.
Instead, Pods generates the exact transaction bytecode required for the user’s wallet to sign and execute.
This means:
- no wrapper contracts
- no proxy logic
- no hidden execution layers
What the user signs is exactly what gets executed.
Removing intermediary contracts eliminates one of the most common sources of vulnerabilities in DeFi integrations: execution layers that sit between the user and the protocol.
Verifying Bytecode Integrity
A common question from integrating teams is:
How can we verify that the transaction payload was not altered between generation and execution?
Pods is designed to work alongside the verification infrastructure already used by exchanges and wallets.
Two mechanisms are commonly used.
Transaction Simulation
Transactions can be simulated before execution using security services such as Blockaid.
Simulation helps detect unexpected contract interactions, token transfers, or state transitions before a transaction is approved.
We strongly recommend running simulation infrastructure across the entire wallet stack.
Transaction Policies
Many wallet infrastructure providers and custodial platforms allow organizations to enforce execution policies.
Examples include:
- Privy
- Dynamic
- Fireblocks
These systems allow teams to define rules such as:
- allowed contract addresses
- protocol-specific allowlists
- transaction size limits
For example, if a platform integrates Aave, the relevant Aave contracts can be allowlisted.
If a transaction deviates from those destinations, it fails automatically.
Our team is happy to assist partners in configuring these policies.
Bytecode Is Not a Playground
The bytecode generated by Pods is designed to execute a specific action safely and deterministically.
It should not be modified.
If additional execution steps or integrations are required, teams should coordinate with the Pods team before modifying transaction payloads.
Even small changes at the bytecode level can introduce unintended side effects.
Security issues often emerge from subtle edge cases that are not immediately visible during development.
For that reason, Pods treats execution bytecode as production infrastructure rather than something to experiment with.
Enterprise Security Considerations
Enterprise platforms operate under strict operational, security, and compliance requirements.
Any infrastructure integrated into a production financial system must meet the same standards applied to custody, transaction authorization, and risk management systems.
Pods is designed to integrate into these environments without introducing additional custody or execution risks.
Transparent Transaction Construction
Pods generates deterministic transaction payloads that can be inspected before execution.
Security teams can:
- review transaction payloads prior to signing
- simulate transactions using internal security tooling
- validate contract destinations and parameters
No execution logic is hidden behind intermediary contracts.
Compatibility with Enterprise Security Infrastructure
Pods works alongside existing transaction security infrastructure used by exchanges and fintech platforms.
Typical integrations include:
Transaction simulation
Platforms such as Blockaid allow transactions to be simulated prior to execution.
Policy enforcement
Wallet infrastructure providers and custodial platforms such as Fireblocks allow organizations to enforce execution rules and allowlists.
Pods-generated transactions can be evaluated against these policies before execution.
Non-Custodial Architecture
Pods does not custody assets and does not move funds on behalf of users.
Transactions are signed and executed directly by:
- the user’s wallet, or
- the integrating platform’s custody provider.
Pods only generates the transaction payload required to interact with the underlying protocol.
This architecture removes the operational and regulatory risks associated with systems that intermediate user funds.
Security Track Record
The security approach behind Pods is informed by the team’s previous experience building and securing DeFi infrastructure.
In prior projects, the team has worked closely with leading security organizations and participated in industry security initiatives.
Notably:
Smart Contract Audits
Our previous protocol underwent two independent smart contract audits conducted by OpenZeppelin, one of the most respected security firms in the blockchain ecosystem.
DeFiSafety Ranking
The protocol was ranked among the Top 3 protocols on DeFiSafety, an independent platform that evaluates the security posture and transparency of DeFi projects.
Other Achievements
Our dedication to ensuring top-notch security extends beyond audits and quality reviews. Below are some of our other achievements and initiatives that underscore our commitment to security.
Event Presentations
We believe in sharing our knowledge and expertise to foster a more secure crypto landscape. Our team delivered a presentation on security best practices at EthCC[4], emphasizing the importance of rigorous security protocols in the development and management of DeFi projects.
Recognition on Social Media
Our security efforts have been recognized and applauded by various security companies on social media. These acknowledgments attest to the effectiveness of our security measures and our proactive approach in maintaining a secure environment for our users.
- First project to implement Trail of Bits Crytic properties
- Fastest payment in a bug bounty from Immunefi
Parallel Projects
In our pursuit of a more secure crypto ecosystem, we initiated parallel projects focused on security. These projects explore new methodologies and technologies to enhance security in DeFi. One example is a tool to perform long fuzzy testing using Echidna on remote machines:
These experiences helped shape the architectural decisions behind Pods.
Security is treated as a design constraint applied from the beginning of system architecture.
Security Recommendations for Integrators
While Pods is designed to minimize additional execution risk, secure integrations also depend on the operational practices of the integrating platform.
We recommend the following security measures when deploying Pods in production environments:
- simulate transactions before execution
- enforce transaction policies and contract allowlists
- monitor protocol dependencies and contract upgrades
- apply standard operational security practices across wallet infrastructure
Our team works closely with partners to help configure these safeguards.
Conclusion
At Pods, security is not treated as a feature layer.
It is a design constraint applied at the architectural level.
By avoiding intermediary smart contracts, generating transparent transaction payloads, and remaining compatible with enterprise security infrastructure, Pods allows teams to integrate onchain capabilities while maintaining their existing security controls.
The goal is simple:
Enable faster product development without increasing the risk surface.