/contracts/abi

This page is for developers who want to integrate with Dealers.sh contracts directly. It points to the contract source, lists the ways you can get ABIs, and outlines the conventions used across the codebase so you know what to expect.

Where the source lives

The Dealers.sh contract source lives in the dealers-exe-contracts/ directory of the project repository. The Solidity layout in src/ matches the contract table on /contracts/overview one-to-one: each row in that table corresponds to a deployed contract under src/core/, src/nft/, src/social/, or src/utils/. ABIs are emitted by forge build into the standard Foundry out/ directory, with one JSON artefact per contract (out/<ContractName>.sol/<ContractName>.json).

How to get ABIs

There are two reliable ways to obtain machine-readable ABIs for any of the deployed contracts. The first is the block explorer itself: every verified contract page on Abstract exposes its full ABI as a JSON file, which you can copy directly into your tooling. The second is to build the contracts locally — forge build (or forge build --zksync --skip "RendererSVG" for the zkSync-native modules) produces a Foundry artefact for every contract under out/, and the .abi field on each artefact is the standard JSON ABI that viem, ethers, and wagmi consume directly.

Conventions across the codebase

A handful of conventions hold consistently across every contract in the system. The contracts are written in Solidity 0.8.x with strict no-libraries policies on critical paths, on the principle that fewer dependencies are easier to audit than fancier ones. Every revert path uses custom errors rather than revert strings, which makes integration debugging easier and keeps gas costs low. Events are documented inline in the source so that anyone reading the contract can quickly see what notifications it emits.

A recommended reading order

If you want to read the entire codebase end to end, the order below is the one we recommend. It moves from data to logic, then to the auxiliary systems, then to the rendering layer.

Start with DealersNFT to understand the data layout and the per-token storage model. Then read DealersActions to see how user calls are dispatched to the action modules. Follow with DealersPVE, which is the most heavily used path in the game, and then DealersPVP as the second most heavily used. DealersHeists rounds out the action modules — it is also the one contract that integrates an external oracle, consuming Pyth Entropy for the jackpot draw. After those, the two registries (DEDrugRegistry and DEAreaRegistry) round out the data model. Finally, the two renderers (DealerRendererSVG and DealerRendererHTML) show how the art and the embedded game are assembled from on-chain primitives.

DealersMulticall is plumbing rather than business logic, and you can safely skip it on a first read.