The ABI and verification
Download it
| ABI | /abi/corelayer.abi.json |
| Crate | corelayer 1.0.0 |
| Framework | multiversx-sc 0.66.2 |
| Contents | 86 endpoints (55 state-changing, 31 views), 54 events, 73 types |
This file is the contract crate's own build artefact, copied into this site on every build. It is also what the reference pages in this section are generated from, which is why they cannot describe a contract other than the one that was built.
curl -sSO https://docs.co-relayer.com/abi/corelayer.abi.json
Using it
Any MultiversX SDK that consumes an ABI will build calls and decode results for you:
// The shape is the same in every MultiversX SDK: load the ABI, point it at an address, call a view.
const abi = await fetch('https://docs.co-relayer.com/abi/corelayer.abi.json').then((r) => r.json());
The ABI carries the Rust doc comments, so a generated client's own documentation says what the code says.
Three things to keep in mind when you talk to the contract directly:
- Pin the address in your own configuration. Take it from your deployment, not from an API response and not from a discovery file. Key the pin by chain id.
- Views cost nothing. Read-only calls through a node's query endpoint need no gas and no permission. Use them to verify anything we tell you.
- Arguments are encoded, and wrong encoding costs somebody gas. The number of arguments and their top-encoding matter — for example, the pay-as-you-go flag call takes four arguments. A call that fails to decode still costs a fee, and on our free purchase flow that fee is paid by our relayer. Encode against the ABI, not against an example.
Checking that the deployed code is the built code
The procedure, in the order that makes each step meaningful:
| Step | What it proves |
|---|---|
| Reproducible build | Building the published source with the published toolchain yields the same wasm, byte for byte. The build metadata in the ABI names the compiler version and the framework version it was built with. |
| Code hash on chain | The account's code hash is the hash of the deployed bytes. Compare it with the hash of your own build. |
| Published source | The source is submitted for verification on the explorer, so the explorer shows the code and the hash together. |
| Deploy-time gate | The hash deployed to mainnet must equal the hash that passed the devnet exit criteria. This is enforced by the deploy procedure, not by a reviewer remembering to check. |
Where this stands: the contract builds, and its test suite passes. The reproducible build and the explorer verification are open work. This page will not pretend otherwise; when each step exists it is published in the changelog, with the explorer link.
The upgrade rule
An upgrade reverts unless all four money scopes are paused first: everything, settlement, renewals and distribution. Without that rule, unverified code would begin running on live money paths from the first block after the upgrade — including the paths that keep running while the contract is otherwise paused. (Overview)
upgraded is an event, so an upgrade is not something that can happen quietly.
Events, for mirroring
If you mirror contract state, match on topics[0] — the identifier in
the events reference.
Every event carries a meta member with an event_seq and a millisecond timestamp_ms. The
sequence is what lets a mirror prove it has missed nothing: a gap in event_seq stops the mirror
rather than being silently skipped. A mirror that quietly skips an event is worse than one that
stops, because the state it reports afterwards is wrong in a way nobody can see.
The events worth watching, by what they tell you:
| Event | Meaning |
|---|---|
tariffScheduled, tariffActivated, tariffPendingCancelled | The price lever. The scheduled one is the 48-hour notice. |
ruScheduleScheduled, ruScheduleActivated | The Relay Unit formula, under the same notice. |
tierSaved, tierActivated, tierStatusChanged | The ladder. |
deposit, paymentSwapped, subscribed, renewed | Money in, and what it bought. |
usageSettled, paygSettled, settleLineRejected | Consumption being reported and accepted — or rejected. |
relayerAdded, relayerStateChanged, relayerWeightsChanged | The registry. |
pauseChanged, settlementPaused, distributionPauseChanged | Operational state. |
poolDistributed, distributionDeferred | The relayer pool. |
upgraded | The code changed. |
The Relay Unit schedule hash
The contract stores the version and a hash of the Relay Unit schedule — the
document defining how a transaction becomes a number of units. Read them with
getRuSchedule and compare the hash against the document you read.
That is what makes the formula verifiable rather than merely published: the owner has committed to a specific document on chain, and changing it carries the same 48 hours of notice as a price increase.