OTP-002: Contract ABI
The contract’s Application Binary Interface (ABI) defines a format containing information about the contract’s receivers, data structures, getters, etc.
Motivation
An ABI is a tool that allows developers to generate convenient bindings, UIs, and so on. A beneficial consumer use case would be a DAO, as it would enable users to confirm exactly what the DAO is attempting to do before signing a transaction.
Specification
An ABI is defined as a JSON file, usually with an .abi
extension:
{ "name": "MyContract", "types": [ { "name": "StateInit", "header": null, "fields": [ { "name": "code", "type": { "kind": "simple", "type": "cell", "optional": false } }, { "name": "data", "type": { "kind": "simple", "type": "cell", "optional": false } } ] }, // ...etc. ], "receivers": [ { "receiver": "internal", "message": { "kind": "text", "text": "Vote!" } }, { "receiver": "internal", "message": { "kind": "typed", "type": "Deploy" } } ], "getters": [ { "name": "gas", "methodId": 92180, "arguments": [], "returnType": { "kind": "simple", "type": "int", "optional": false, "format": 257 } } ], "errors": { "2": { "message": "Stack underflow" }, "3": { "message": "Stack overflow" } // ...etc. }, "interfaces": [ "org.ton.introspection.v0", "org.ton.abi.ipfs.v0", "org.ton.deploy.lazy.v0", "org.ton.debug.v0" ]}
Drawbacks
-
The ABI is in JSON format, which is both human- and machine-readable, but not the most compact. A binary representation could be better but is not critical for now.
-
The ABI has no strict JSON or TypeScript schema defined and thus is subject to frequent changes.
Prior art
- OTP-001: A complementary proposal that provides additional context.