> For the complete documentation index, see [llms.txt](https://docs.metalex.tech/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.metalex.tech/protocol-how-to-guides/integrate-from-frontend.md).

# 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`](https://github.com/MetaLex-Tech/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

```ts
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`](https://github.com/MetaLex-Tech/cybercorps-contracts/blob/develop/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](/protocol-explanation/application-stack.md).
* The Web App section of these docs covers the live apps from a user's perspective.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.metalex.tech/protocol-how-to-guides/integrate-from-frontend.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.