The Mexas Whitepaper

Download the whitepaper PDF · 401 KB

In brief

Mexas (ticker MEX) is a stablecoin designed to hold a one-to-one peg with the Mexican peso, intended to be backed one-to-one by peso-denominated reserves held with regulated financial institutions and segregated from operating funds. It is issued as a standard token on public, permissionless blockchains, so a peso balance can move with the speed, reach and programmability of a blockchain transfer while staying denominated in the currency its holder earns, prices and spends in.

The paper sets out the case for a peso stablecoin in a market where roughly half of adults have no bank account, remittances exceeded US$64 billion in 2024 and transfer fees run between 2% and 9%; the economic model and reserve framework; the technical architecture across six networks; the oversight, audit and compliance arrangements; the use cases, from remittances and merchant payments to treasury and on-chain finance; and the risks, including the ones that follow directly from the design rather than from market conditions.

What the paper covers

1. Introduction. Stablecoins and their significance, the Mexican opportunity, and the design principles behind Mexas.
2. Economic model and reserve management. Collateralization, the wholesale issuance and redemption process, and the roles involved.
3. Technical architecture. Token specification, the upgradeable contract, and the compliance and security features it contains.
4. Oversight and risk management. Transparency and financial auditing, the CertiK security audit, and the AML/CFT framework.
5. Regulatory framework. Mexico’s regulatory landscape and the positioning of Mexas within it.
6. Use cases. Cross-border remittances, domestic payments, on-chain finance and corporate treasury.
7. Risk factors and mitigation. Regulatory, reserve, peg, technology, issuer-control, competition and operational risk.
8. Mexas in the stablecoin ecosystem. Why a peso instrument complements dollar-pegged ones.
9. Appendices. Technical specifications and contract addresses, audit and attestation reports, glossary, and references.

Key points

A summary of the points readers ask about most. The paper itself is the full statement; where this page and the PDF differ, read the PDF.

Issuance and redemption are wholesale

Tokens are put into circulation only against pesos received. A liquidity provider sends pesos to the issuer, the issuer releases the corresponding Mexas to that provider, and the reverse on redemption, where the returned tokens are retired. Minting is a privileged action available only to the owner role, so no supply can be created except by the issuer.

What this means if you hold Mexas. You do not have a direct redemption right against the issuer. You sell your tokens to a liquidity provider or distribution partner, on that party’s terms, and that party settles with the issuer. Commercial terms — minimum sizes, fees and settlement times — are agreed bilaterally and are not published.

Six networks, six independent ledgers

Mexas is deployed on five EVM networks — Ethereum, Arbitrum One, Avalanche C-Chain, Base and BNB Smart Chain — as an ERC-20 token with 6 decimals, and on the Liquid Network as a native issued asset with 8 decimals. Each deployment is an independent ledger with its own supply. Holding Mexas on one network is not a claim on another, there is no bridge between them, and no transaction on one network mints or burns tokens on any other.

Every contract address is listed with its chain ID and explorer link on this website and in Appendix A of the paper. Two cautions when you copy one. The same address appears on more than one network, but those are separate contracts — always take the address from the row for the network you are actually using. And counterfeit tokens are routinely deployed at addresses matching a real one at the first and last few characters, which is all most wallets display: compare the whole string, and take it from this website rather than from a message, a reply or an advertisement.

The contract and who controls it

Each EVM deployment is a proxy at the token address delegating to a replaceable implementation contract, following the UUPS pattern — so upgrade authority belongs to the contract’s owner, and that one role carries every privileged power:

• Mint. Create tokens to any address. There is no cap written into the contract.
• Redeem. Burn tokens held at the owner address, retiring them from supply.
• Block an address. A blocked address cannot send, approve or sign a permit, and cannot receive newly minted tokens. Others can still send tokens to it, so tokens sent there become frozen.
• Destroy a blocked balance. Permanently, without the holder’s consent and without compensation on-chain.
• Pause. Halt every transfer, mint and burn at once, until unpaused.
• Upgrade. Replace the implementation with different code, at the same token address, with immediate effect and no timelock.

We would rather state those powers plainly than leave a reader to discover them in the bytecode. The owner role is held by a multisig wallet on each network, requiring signatures from several holders, so no single key can mint, pause, block or upgrade. To date none of the control powers has been used on any network: no address blocked, no balance destroyed, no token paused, and no implementation replaced since deployment. Every use would be a permanent public event, so that statement is checkable rather than merely asserted. The Liquid asset works differently: it has no pause, upgrade or blocklist mechanism of any kind, and its only privileged power is reissuance.

The upgrade power contains all the others: an upgrade could add a mint path, change how the blocklist behaves, or introduce a control that does not exist today. Upgradeability is a real trust assumption, not a formality.

Reserves and transparency

Reserves are intended to be held in peso-denominated form with regulated financial institutions, segregated from the issuer’s operating funds. The figure they must cover is circulating supply, summed across every network; because the deployments are independent ledgers, a reserve statement covering one network says nothing about the others.

A stablecoin makes two promises that are verified in completely different ways. The token side — supply, transfers, balances and contract code — is public on every network and requires trusting nobody. The reserve side sits in bank accounts, which no blockchain can see, and requires an independent audit. Every quarter, the accounting firm Ferrer & Asociados checks the reserves against circulating supply on every network, and its reports are published in full on the Audit Reports page. They rest on bank information the issuer supplies to the auditor, so the reserve side still requires trusting the auditor.

Smart contract audit

The Mexas token contract was audited by CertiK, with a final report published on 12 May 2026, covering contracts/MEXAS.sol using formal verification, manual review and static analysis. It found no critical, major or medium issues. Two centralization findings concern the owner role’s powers and are mitigated by multisig ownership, which CertiK notes reduces the risk without eliminating it; one minor coding-style finding was acknowledged. CertiK also recommended a timelock on privileged actions and advance notice of upgrades, neither of which is in place. The deployed contracts on every network run the audited code.

The full report is on the Audit Reports page, or you can read it directly (PDF). An audit reviews code at a point in time — it is not a guarantee of correctness, and any future upgrade would fall outside it.

Verifying the token yourself

Every technical claim above can be checked directly against the networks, without asking us for anything: name(), symbol() and decimals() for token identity, totalSupply() for supply, owner() for who holds the privileged powers, paused() for whether transfers are halted, isBlocked(address) and the BlockPlaced, BlockReleased and DestroyedBlockedFunds event history for the blocklist, and the Mint and Redeem logs for every issuance and retirement. If any of those disagree with this page, the chain is right and this page is wrong. Tell us at contact@mexas.io.

Risks

Mexas is not a bank deposit, is not insured, and is not risk-free. Section 7 of the paper sets out regulatory, reserve and counterparty, peg and liquidity, technology, issuer-control and upgrade, competition and operational risk, with the mitigation applied to each; the full contractual statement is in the Terms & Conditions. Three follow directly from the design rather than from market conditions. Issuer control risk: on the EVM networks your balance can be frozen and destroyed by the owner role, and all transfers can be paused. Upgrade risk: the same role can give the token different behaviour, at the same address, without notice or timelock. Issuer risk on redemption: on-chain transparency proves how many tokens exist, not that the reserves behind them exist or that a redemption will be honoured.