REA Concept
Last updated
Last updated
Compared to traditional financial transactions, blockchain transactions are often more complex, making the underlying events they represent difficult to understand. This complexity is further exacerbated when transactions involve smart contracts. Due to the decentralized nature of blockchain, anyone can create smart contracts without clear rules, leading to an increasing number of difficult-to-interpret transactions.
This presents two problems:
Lack of Clarity: Ordinary users find it challenging to understand the impact behind blockchain transactions, preventing accurate financial analysis.
Integration Difficulties: Traditional platforms face compatibility issues when integrating blockchain transactions, hindering the broader application of blockchain technology.
To address these issues, we need a standardized and normalized information model that can handle blockchain transactions in a user and system-compatible manner.
REA (Resource, Event, Agent) is a perfect solution. REA is a new accounting information model proposed by William E. McCarthy in 1982. It is an original description method of a business's economic activities, modeling the important resources, events, participants, and their interrelationships. It centralizes the storage of all business-related content (financial and non-financial) in databases by their actual semantics rather than artificially processed debit and credit entries.
The three main features of the REA model are data-based, semantic-based, and structure-based. These features meet the need to understand and store blockchain transactions and can be accepted by traditional ERP systems. Here is an example demonstrating the information results interpreted based on the REA model.
Blockchain Tx | REA Interpretation |
---|---|
Events | Resources | Agents (from) | Agents (to) |
---|---|---|---|
Through the Mest Protocol, anyone can annotate an Agent for a blockchain address, and if the address is a smart contract, they can also annotate Event information for the corresponding contract method.
The tags represent labels related to the address, divided into two types: agent and event:
Agent tag ["agent", "agent name", "tag submission ID"]
Event tag ["event", "event name", "contract method signature", "tag submission ID"]
Each address can contain multiple agent and event tags, and how these tags will be used is up to the application layer to decide, such as introducing a voting mechanism to select consensus labels, etc.
0x37cd2a3f7c1bf25276b39f629677d10c0d32a7a0ab8fa24c9ef15ad2c9a7afa6
0xbed…7c6b repaid a loan principal of 2,000 USDC to Aave Protocol v2
0xbed…7c6b paid a loan interest of 340.35 USDC to Aave Protocol v2
0xbed…7c6b paid a gas fee of 0.0066 ETH to Ethereum Validator
repay (loan principal)
2,000 USDC ($2,000)
0xbed...7c6b
Aave Protocol v2
pay (loan interest)
340.353418 USDC ($340.35)
0xbed...7c6b
Aave Protocol v2
pay (gas)
0.006266591 ETH ($10.8)
0xbed...7c6b
Ethereum Validator