Integrate from a frontend

Wire a dApp frontend to the cyberCORPs contracts

This guide covers calling the protocol from a TypeScript / React app. The reference UIs live in metalex-webapp.

Recommended stack

• wagmi + viem for contract calls and typed ABIs.
• A wallet connector (injected wallets, WalletConnect).
• An indexer for list/aggregate reads (cap tables, rounds) rather than many direct contract reads.

Reading contract state

import { useReadContract } from "wagmi";
import { cyberCorpAbi } from "@/abis";

const { data: name } = useReadContract({
  abi: cyberCorpAbi,
  address: cyberCorpAddress,
  functionName: "cyberCORPName",
});

Note the real getters: cyberCORPName, cyberCORPType, cyberCORPJurisdiction on CyberCorp; legalOwnerOf vs ownerOf on the cert printer (the LedgerEntryToken contract, formerly CyberCertPrinter — the rename did not change the ABI).

Writing transactions

Use useWriteContract. State-changing calls go through the cyberCORP's manager contracts — IssuanceManager, DealManager, RoundManager — not directly to LedgerEntryToken / CyberScrip (those are mostly onlyIssuanceManager, with some admin-gated exceptions on the cert printer). The DealManager's secondary-trade entry points (postOffer, acceptOffer, cancelOffer) each have a relayed overload (…, forAddr, nonce, sig) for gasless UX; voidSecondaryTradeAgreement's relayed form differs — (agreementId, signer, voidSignature, nonce, authSig).

Atomic fee + formation via Multicall3

A USDC platform fee and a CyberCorpFactory deployment can be batched into one transaction through the canonical Multicall3 (0xcA11bde05977b3631167028862bE2a173976CA11): the fee travels as an EIP-3009 transferWithAuthorization (the user signs typed data naming the recipient, amount, validity window, and a random nonce), and the formation call takes the owner as a parameter — so neither inner call depends on msg.sender, and Multicall3 being the sender of both is harmless.

The batch is all-or-nothing only if you set allowFailure: false on both Call3 entries — that is what makes aggregate3 revert the whole transaction when either call fails. With allowFailure: true, Multicall3 continues past a failed call: the suite's test_frontRunAuthorizationToleratedWithAllowFailure shows formation succeeding while the fee call fails, which as a frontend default would deploy the corp without collecting the fee.

The strictness is scoped to the batch, not to the signed authorization: an EIP-3009 authorization is submittable by anyone, so a front-runner can mine it directly before your batch, transferring the fee to its named recipient and leaving the strict batch to revert on the consumed nonce with nothing deployed (test_frontRunAuthorizationRevertsTheStrictBatch). Handle that case explicitly — detect the used nonce, verify where the fee went, and reconcile before asking the user to sign a fresh authorization — rather than treating a batch revert as "nothing happened". See test/MulticallFormationFeeForkTest.t.sol for a worked Base-mainnet example, including the TransferWithAuthorization typed-data struct.

EIP-712 signatures

cyberRAISE EOIs, deal counter-signatures, and cyberSign agreements are EIP-712 typed-data signatures, produced with viem's signTypedData. The CyberAgreementRegistry underlies all of them — a round EOI and a deal both resolve to a registry contract identified by a bytes32 id.

Rendering a cyberCERT

tokenURI(tokenId) on the cert printer returns a base64 data: JSON whose image is an onchain-rendered SVG. Decode the JSON, then render the SVG. (There is no un-encoded JSON getter on the printer — base64-decode the data: payload for the raw JSON.)

ABIs

Keep your ABIs in sync with the deployed contracts. Each contract exposes its own DEPLOY_VERSION — at time of writing "4.1" for IssuanceManager, "4.0.1" for DealManager, and "4" for CyberCorp, RoundManager, LedgerEntryToken, and CyberScrip. The protocol is under active development; regenerate ABIs when implementations change.

Related

• Application stack.
• The Web App section of these docs covers the live apps from a user's perspective.