Skip to main content

OKcontract Approach

Each interaction starts with the user intent:

  • User wants to swap X A tokens for Y B tokens and stake B tokens
  • User wants to add liquidity to a pool
  • User wants to migrate liquidity from one pool to another
  • User wants to borrow assets
  • User wants to mint an NFT
  • User wants to buy the floor of a NFT collection

To implement a smart contract interaction on the client-side, developers need: a smart contract address, a method, an ABI and few SDKs.

For methods with parameters, developers need to:

  • Read data from contracts
  • Get user state and react to user inputs
  • Format and compute amounts, deadline
  • Listen to events like chain changes and wallet changes
  • Customize interactions with the wallet balance of a given token
  • Compute slippage
  • Provide gas estimation
  • Compute and convert currencies
  • Include approvals: Even when developers want users to perform a single transaction, they might need two.
  • In some cases, they need to call other contracts to get data and inputs. To migrate DeFi pools, six transactions might be necessary.

The semantics of transaction requires assembling the parameters and getting the right inputs in that transaction.

Developer Hurdles​

Developers face multiple challenges due to the differences between the mutable world of JavaScript and the decentralized immutable world of blockchains:

  • The semantics of interacting with blockchains are not specified
  • The actual client-side computations are lost or fragmented in the JavaScript codebase.
  • There is no standard way to get the data required to compute the transaction parameters, developers have to manually implement onchain and off-chain data.
  • Each transactional interface requires additional implementation, making the codebase hard to maintain and protect from vulnerabilities.

Our Approach​

At OKcontract, we focus on standardization and automation. Our approach to properly implement and handle blockchain interactions, boils down to the following:

  • A standard way to specify a smart contract interaction
  • Automated generation of the transactional interface from that specification
  • Streamlined integration of that generated interaction into any cunsumer or business app
  • An open access for AI agents to query and invoke interactions
  • Transaction parameters computation from high-level inputs
  • An aggregated access to all required onchain and off-chain data
  • A common runtime for all interactions

Smart Contract Implementation​

A Common Monolithic Approach​

Most projects use a monolithic approach to implement smart contract interactions:

  • Smart contract interactions are implemented into a large monolithic codebase. Developers write hundreds of lines of code for each method of the contract and even more for managing various other aspects like wallet changes, balances, and approvals.
  • Each dApp implements a separate API to interact with blockchain and stores it on a centralized server, such as AWS.
  • dApps are usually operated by project teams and their availability relies on these teams

Challenges of Monolitic Implementation​

Large codebases, sprawling with hundreds or thousands of lines, present significant challenges:

  • The transaction semantics are fragmented and spread over numerous lines of JavaScript code.
  • The code complexity and heavy dependencies make verification and maintenance arduous. Constant evolution of the codebase necessitates frequent audits, which are rarely performed.
  • The reliance on centralized API nodes make frontends vulnerable to regulatory censorship.

Our Approach: Separating Specifications and Runtime​

OKcontract standardizes onchain interactions with smart contracts, tokens, NFTs utilizing low-level intent specification using its DSL, called Lambdascript.

We are rethinking the smart contract interaction implementation. Our approach splits interaction specification from the runtime engine.

The transaction semantics are abstracted away from the JavaScript codebase to clarify interaction definition which is usually spread of numerous JavaScript files. The definitions are separated from the common runtime engine. This approach is further enhanced by an automated UI generation layer, enhancing security.

The separation between specification and runtime drastically reduces the code volume and simplifies verification. A significantly shorter interaction specifications (dozens of lines instead of thousands of lines of JavaScript code/libs/hooks) makes them considerably easier to audit. This opens the path to community-based attestations for contract interaction specifications.

OKcontract's common generation runtime, combined with automated UI generation, empowers developers to quickly create default frontends. This workflow allows for the generation of user interfaces for any smart contract ABI method, token, or NFT. The generated interfaces are customizable, easy to preview and test. Their integration into web apps or sites is simple thanks to the OKcontract SDK or embeddable HTML UI snippets that can be copied and pasted.

Safe and Reusable Middleware for AI Agents​

With AI agents automating tasks like yield-farming strategies, stablecoin treasury management, and NFT curation, it seems inevitable that humans will shift from manual DeFi actions to delegating these tasks to automated systems. But automating on-chain activities at scale comes with substantial security and reliability risks. AI agents can misunderstand user prompts, reference the wrong contract code, or generate malformed transactions — leading to costly errors that include loss of funds. As more people trust AI agents to manage their onchain operations, the underlying infrastructure must be robust, predictable, and verifiable.

Why On-the-Fly Code Generation Falls Short​

A common approach is to let AI generate transactions “on-the-fly” — implement the smart contract logic, bytecode calls, and transaction data. However, this approach is notoriously dangerous for blockchain use:

  • Corrupted Output: Even small syntax errors can break a transaction script or produce a malformed call.
  • Security Gaps: Dynamically generated code might fail to account for necessary security checks.
  • Unverified Dependencies: Contract addresses or libraries the AI references on the spot may not be audited or could be outright malicious.
  • Zero Reproducibility: Continuous generation leads to ephemeral code paths that are hard to track, audit, and debug over time.

When an AI agent attempts to generate or stitch together new code on-the-fly, it’s easy to get any of these details wrong. LLMs can confidently produce incorrect or partially correct code — commonly referred to as “hallucinations.” When dealing with financial transactions and real money, an AI agent mixing up a function name or referencing an outdated library can have catastrophic consequences.

The blockchain ecosystem features thousands of smart contracts, many of which have similar programmable interfaces but differ in critical ways. An AI agent might accidentally reference an unverified or malicious contract, or inject code from a library that hasn’t been thoroughly vetted — putting user funds at risk.

Users will increasingly give high-level, natural-language commands to their AI. If an AI agent misinterprets something like “swap half my USDC for ETH,” it could do anything from sending all tokens to the wrong address to creating an unwanted or partial transaction.

OKcontract Interaction Catalog​

Instead of relying on AI to cobble together contract calls from scratch, OKcontract offers a catalog of validated interaction specifications for swaps, staking, lending, adding liquidity, minting, etc.

These interactions:

  • Include clear parameters for slippage, gas usage, security checks, etc.
  • Can be attested by the community via EAS (Ethereum Attestation Service) and thoroughly curated by the OKcontract community.
  • Can be referenced by an AI agent as a known-safe building block, rather than free-styling new code.

Rather than generating contract function calls in JavaScript, an AI agent merely needs to identify the correct “Interaction ID” from the OKcontract catalog and provide input parameters (e.g., “the amount of tokens to swap”). The endpoint responds with:

  • Secure Transaction Data: No guesswork about function signatures or bytecode.
  • Validated Workflows: Any additional steps — like approving a token spend or verifying a price feed — are built into the pre-defined interaction.

By referencing known contract interactions:

  • AI agents avoid referencing incorrect or malicious bytecode.
  • Interaction specs remain small and easy to verify, while OKcontract Protocol ensures stable transaction building within thrid-party environments.
  • The community can audit and attest each interaction template, reducing security risks.

This approach allows us to eliminate hallucinations and contract mix-ups.