Chapter 4: Phase 1 - Data Format and Standards
The Foundation of Interoperability
Before blockchains can communicate, they must speak a common language. Phase 1 of the WIA standard defines universal data formats, transaction schemas, and token standards that work seamlessly across all blockchain networks.
Phase 1 is the foundational layer of the WIA standard. It establishes how blockchain financial data is structured, validated, and transmitted. By creating a universal data format that works across all major blockchains, Phase 1 enables the interoperability, security, and efficiency that the higher phases build upon.
4.1 Universal Transaction Schema
Every blockchain has its own transaction format. Ethereum uses RLP encoding, Bitcoin uses its own binary format, Solana uses Borsh serialization, and Cosmos uses Protocol Buffers. This fragmentation makes it nearly impossible to build applications that work across chains.
The WIA Universal Transaction Schema provides a chain-agnostic format that can represent any blockchain transaction while maintaining compatibility with native formats.
Core Transaction Structure
{
"version": "1.0.0",
"id": "wia:tx:0x1234...abcd",
"type": "transfer|swap|stake|bridge|contract_call",
"timestamp": 1735084800000,
"source": {
"chainId": 1,
"chainName": "ethereum",
"address": "0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb",
"nonce": 42
},
"destination": {
"chainId": 1,
"chainName": "ethereum",
"address": "0x8ba1f109551bD432803012645Ac136ddd64DBA72"
},
"asset": {
"type": "WIA-20",
"address": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
"symbol": "USDC",
"decimals": 6,
"amount": "1000000000",
"amountFormatted": "1000.00"
},
"fee": {
"asset": "ETH",
"amount": "21000000000000",
"amountFormatted": "0.000021",
"usdValue": "0.042"
},
"status": "pending|confirmed|failed",
"confirmations": 0,
"blockNumber": 18500000,
"blockHash": "0xabc...def",
"signature": {
"v": 27,
"r": "0x123...",
"s": "0x456..."
},
"metadata": {
"intent": "Send 1000 USDC to Alice",
"tags": ["payment", "business"],
"notes": "Invoice #12345"
}
}
Field Specifications
| Field | Type | Required | Description |
|---|---|---|---|
| version | string | ✅ | WIA schema version (semantic versioning) |
| id | string | ✅ | Unique identifier with format: wia:tx:{hash} |
| type | enum | ✅ | Transaction type for categorization |
| timestamp | number | ✅ | Unix timestamp in milliseconds (UTC) |
| source | object | ✅ | Origin chain and address information |
| destination | object | ❌ | Target chain and address (optional for contract calls) |
| asset | object | ✅ | Asset being transferred with full details |
| fee | object | ✅ | Transaction fee details including USD value |
| status | enum | ✅ | Current transaction state |
| metadata | object | ❌ | Optional user-defined metadata |
Cross-Chain Transaction Example
Here's how a cross-chain bridge transaction is represented:
{
"version": "1.0.0",
"id": "wia:tx:bridge:0xabc123",
"type": "bridge",
"timestamp": 1735084800000,
"source": {
"chainId": 1,
"chainName": "ethereum",
"address": "0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb",
"nonce": 42
},
"destination": {
"chainId": 137,
"chainName": "polygon",
"address": "0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb"
},
"asset": {
"type": "WIA-20",
"address": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
"symbol": "USDC",
"decimals": 6,
"amount": "5000000000",
"amountFormatted": "5000.00"
},
"bridge": {
"protocol": "WIA-Bridge",
"validators": [
"0x123...",
"0x456...",
"0x789..."
],
"requiredSignatures": 5,
"actualSignatures": 7,
"estimatedArrival": 1735085100000,
"sourceTransactionHash": "0xeth123...",
"destinationTransactionHash": "0xpoly456...",
"status": "confirmed_on_source|in_transit|confirmed_on_destination"
},
"fee": {
"sourceFee": {
"asset": "ETH",
"amount": "150000000000000",
"usdValue": "0.30"
},
"bridgeFee": {
"asset": "USDC",
"amount": "5000000",
"usdValue": "5.00"
},
"destinationFee": {
"asset": "MATIC",
"amount": "50000000000000000",
"usdValue": "0.05"
},
"totalUsdValue": "5.35"
}
}
4.2 WIA-20: Enhanced Fungible Token Standard
WIA-20 extends ERC-20 with cross-chain capabilities, enhanced metadata, and compliance hooks while maintaining 100% backward compatibility.
Interface Definition
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
interface IWIA20 is IERC20 {
// ============ Cross-Chain Extensions ============
/// @notice Transfer tokens to another blockchain
/// @param destinationChainId Target blockchain chain ID
/// @param destinationAddress Recipient address on destination chain
/// @param amount Amount to transfer
/// @param data Additional data for the transfer
/// @return transferId Unique identifier for tracking the transfer
function crossChainTransfer(
uint256 destinationChainId,
address destinationAddress,
uint256 amount,
bytes calldata data
) external returns (bytes32 transferId);
/// @notice Get the token address on a specific chain
/// @param chainId Target blockchain chain ID
/// @return tokenAddress Address of this token on the target chain
function getChainRepresentation(uint256 chainId)
external view returns (address tokenAddress);
// ============ Enhanced Metadata ============
/// @notice Get comprehensive token metadata
/// @return metadata JSON string containing extended metadata
function getMetadata() external view returns (string memory metadata);
/// @notice Get token logo URI
/// @return uri IPFS or HTTP URI to token logo
function logoURI() external view returns (string memory uri);
/// @notice Get token website
/// @return url Official token website
function website() external view returns (string memory url);
// ============ Compliance Hooks ============
/// @notice Check if transfer is compliant
/// @param from Sender address
/// @param to Recipient address
/// @param amount Transfer amount
/// @return compliant Whether transfer meets compliance requirements
function isTransferCompliant(
address from,
address to,
uint256 amount
) external view returns (bool compliant);
/// @notice Set compliance rules (admin only)
/// @param rulesURI URI to compliance rules document
function setComplianceRules(string calldata rulesURI) external;
// ============ Batch Operations ============
/// @notice Batch transfer to multiple recipients
/// @param recipients Array of recipient addresses
/// @param amounts Array of transfer amounts
function batchTransfer(
address[] calldata recipients,
uint256[] calldata amounts
) external returns (bool);
// ============ Events ============
event CrossChainTransferInitiated(
bytes32 indexed transferId,
uint256 indexed destinationChainId,
address indexed from,
address to,
uint256 amount
);
event CrossChainTransferCompleted(
bytes32 indexed transferId,
uint256 indexed sourceChainId,
address indexed to,
uint256 amount
);
event ComplianceRulesUpdated(string rulesURI);
}
Metadata JSON Schema
{
"$schema": "https://wia.finance/schemas/wia20-metadata-v1.json",
"name": "USD Coin",
"symbol": "USDC",
"decimals": 6,
"totalSupply": "32000000000000000",
"version": "1.0.0",
"description": "USDC is a fully collateralized US Dollar stablecoin",
"website": "https://www.circle.com/usdc",
"logoURI": "ipfs://QmXxXxXx.../usdc-logo.png",
"tags": ["stablecoin", "defi", "payments"],
"chains": [
{
"chainId": 1,
"chainName": "ethereum",
"address": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
"bridgeType": "native",
"verified": true
},
{
"chainId": 137,
"chainName": "polygon",
"address": "0x2791Bca1f2de4661ED88A30C99A7a9449Aa84174",
"bridgeType": "wia-bridge",
"verified": true
}
],
"social": {
"twitter": "https://twitter.com/circle",
"discord": "https://discord.gg/circle",
"telegram": "https://t.me/circle"
},
"compliance": {
"rulesURI": "https://www.circle.com/compliance",
"kycRequired": false,
"amlChecks": true,
"jurisdictionRestrictions": ["US-NY"],
"maximumTransfer": "10000000000"
},
"security": {
"audits": [
{
"auditor": "Trail of Bits",
"date": "2023-06-15",
"reportURI": "ipfs://QmAuditReport123"
}
],
"bugBounty": "https://immunefi.com/bounty/circle"
}
}
Implementation Example
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/access/AccessControl.sol";
import "@openzeppelin/contracts/security/ReentrancyGuard.sol";
contract WIA20Token is ERC20, AccessControl, ReentrancyGuard, IWIA20 {
bytes32 public constant BRIDGE_ROLE = keccak256("BRIDGE_ROLE");
bytes32 public constant COMPLIANCE_ROLE = keccak256("COMPLIANCE_ROLE");
string private _logoURI;
string private _websiteURL;
string private _metadataJSON;
string private _complianceRulesURI;
mapping(uint256 => address) private chainRepresentations;
mapping(bytes32 => bool) private processedTransfers;
constructor(
string memory name_,
string memory symbol_,
uint8 decimals_,
uint256 initialSupply
) ERC20(name_, symbol_) {
_grantRole(DEFAULT_ADMIN_ROLE, msg.sender);
_mint(msg.sender, initialSupply * 10**decimals_);
}
// ============ Cross-Chain Functions ============
function crossChainTransfer(
uint256 destinationChainId,
address destinationAddress,
uint256 amount,
bytes calldata data
) external override nonReentrant returns (bytes32 transferId) {
require(
chainRepresentations[destinationChainId] != address(0),
"Chain not supported"
);
require(balanceOf(msg.sender) >= amount, "Insufficient balance");
// Burn tokens on source chain
_burn(msg.sender, amount);
// Generate unique transfer ID
transferId = keccak256(
abi.encodePacked(
block.chainid,
destinationChainId,
msg.sender,
destinationAddress,
amount,
block.timestamp
)
);
emit CrossChainTransferInitiated(
transferId,
destinationChainId,
msg.sender,
destinationAddress,
amount
);
// Bridge protocol handles the actual cross-chain message
// Implementation depends on bridge architecture (Phase 2)
}
function completeCrossChainTransfer(
bytes32 transferId,
uint256 sourceChainId,
address to,
uint256 amount,
bytes calldata proof
) external onlyRole(BRIDGE_ROLE) nonReentrant {
require(!processedTransfers[transferId], "Already processed");
require(_verifyBridgeProof(proof), "Invalid proof");
processedTransfers[transferId] = true;
// Mint tokens on destination chain
_mint(to, amount);
emit CrossChainTransferCompleted(transferId, sourceChainId, to, amount);
}
function getChainRepresentation(uint256 chainId)
external view override returns (address)
{
return chainRepresentations[chainId];
}
// ============ Metadata Functions ============
function getMetadata() external view override returns (string memory) {
return _metadataJSON;
}
function logoURI() external view override returns (string memory) {
return _logoURI;
}
function website() external view override returns (string memory) {
return _websiteURL;
}
function setMetadata(string calldata metadataJSON)
external onlyRole(DEFAULT_ADMIN_ROLE)
{
_metadataJSON = metadataJSON;
}
// ============ Compliance Functions ============
function isTransferCompliant(
address from,
address to,
uint256 amount
) public view override returns (bool) {
// Example compliance checks
// In production, this would integrate with compliance providers
// Check if addresses are not blacklisted
// Check if amount is within limits
// Check jurisdiction restrictions
return true; // Simplified for example
}
function setComplianceRules(string calldata rulesURI)
external override onlyRole(COMPLIANCE_ROLE)
{
_complianceRulesURI = rulesURI;
emit ComplianceRulesUpdated(rulesURI);
}
function _beforeTokenTransfer(
address from,
address to,
uint256 amount
) internal virtual override {
// Enforce compliance checks on every transfer
if (from != address(0) && to != address(0)) {
require(
isTransferCompliant(from, to, amount),
"Transfer not compliant"
);
}
super._beforeTokenTransfer(from, to, amount);
}
// ============ Batch Operations ============
function batchTransfer(
address[] calldata recipients,
uint256[] calldata amounts
) external override returns (bool) {
require(recipients.length == amounts.length, "Length mismatch");
require(recipients.length <= 200, "Too many recipients");
uint256 totalAmount = 0;
for (uint256 i = 0; i < amounts.length; i++) {
totalAmount += amounts[i];
}
require(balanceOf(msg.sender) >= totalAmount, "Insufficient balance");
for (uint256 i = 0; i < recipients.length; i++) {
_transfer(msg.sender, recipients[i], amounts[i]);
}
return true;
}
// ============ Internal Functions ============
function _verifyBridgeProof(bytes calldata proof)
internal view returns (bool)
{
// Proof verification logic (Phase 2)
// This would verify multi-sig, merkle proofs, etc.
return true; // Simplified
}
}
4.3 WIA-721: Enhanced NFT Standard
WIA-721 extends ERC-721 with cross-chain NFT transfers, enhanced royalties, and fractionalization support.
Key Enhancements
| Feature | ERC-721 | WIA-721 | Benefit |
|---|---|---|---|
| Cross-Chain Transfer | ❌ | ✅ | NFTs can move between blockchains |
| Royalty Standard | ❌ (EIP-2981 optional) | ✅ Built-in | Creators earn royalties on all marketplaces |
| Fractionalization | ❌ | ✅ | NFTs can be divided into tradeable shares |
| On-Chain Metadata | ❌ (usually IPFS) | ✅ Optional | Metadata survives even if IPFS fails |
| Rental Standard | ❌ | ✅ | NFTs can be rented without transferring ownership |
NFT Metadata Schema
{
"$schema": "https://wia.finance/schemas/wia721-metadata-v1.json",
"name": "Bored Ape #1234",
"description": "A unique Bored Ape from the BAYC collection",
"image": "ipfs://QmRRPWG96cmgTn2qSzjwr2qvfNEuhunv6FNeMFGa9bx6mQ",
"animation_url": "ipfs://QmVideo123...",
"external_url": "https://boredapeyachtclub.com/ape/1234",
"attributes": [
{
"trait_type": "Background",
"value": "Army Green"
},
{
"trait_type": "Fur",
"value": "Brown"
},
{
"trait_type": "Eyes",
"value": "3D"
},
{
"trait_type": "Rarity Score",
"value": 342.5,
"display_type": "number"
}
],
"wia_extensions": {
"version": "1.0.0",
"chains": [
{
"chainId": 1,
"chainName": "ethereum",
"contractAddress": "0xBC4CA0EdA7647A8aB7C2061c2E118A18a936f13D",
"tokenId": "1234",
"bridgeType": "native"
},
{
"chainId": 137,
"chainName": "polygon",
"contractAddress": "0xPolygonBAYC...",
"tokenId": "1234",
"bridgeType": "wia-721-bridge"
}
],
"royalty": {
"recipient": "0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb",
"percentage": 5.0,
"currency": "ETH"
},
"fractional": {
"enabled": true,
"totalShares": 1000000,
"shareTokenAddress": "0xFractionToken...",
"vaultAddress": "0xVault..."
},
"rental": {
"enabled": true,
"maxDuration": 2592000,
"minPrice": "100000000000000000",
"currency": "ETH"
},
"unlockable": {
"hasContent": true,
"contentType": "encrypted",
"description": "Exclusive community access"
},
"provenance": [
{
"timestamp": 1619481600000,
"event": "minted",
"from": "0x0000000000000000000000000000000000000000",
"to": "0xCreator...",
"price": "0",
"txHash": "0xMintTx..."
},
{
"timestamp": 1625097600000,
"event": "sale",
"from": "0xCreator...",
"to": "0xCollector1...",
"price": "50000000000000000000",
"marketplace": "OpenSea",
"txHash": "0xSaleTx..."
}
]
}
}
4.4 WIA-1155: Enhanced Multi-Token Standard
WIA-1155 extends ERC-1155 for efficient batch operations and cross-chain multi-token transfers, ideal for gaming and DeFi applications.
Use Cases
- Gaming: Manage thousands of in-game items (weapons, armor, currencies) in a single contract
- Tickets & Events: Different ticket tiers for events with varying supply
- Vouchers & Coupons: Redeemable digital coupons with limited quantities
- Fractional Ownership: Shares of real-world assets with varying classes
// Example: Gaming Item Contract
contract GameItems is WIA1155 {
uint256 public constant GOLD = 0;
uint256 public constant SILVER = 1;
uint256 public constant SWORD = 2;
uint256 public constant SHIELD = 3;
uint256 public constant POTION = 4;
constructor() WIA1155("https://game.example/api/item/{id}.json") {
// Mint fungible currencies
_mint(msg.sender, GOLD, 10000000 * 10**18, "");
_mint(msg.sender, SILVER, 50000000 * 10**18, "");
// Mint semi-fungible items
_mint(msg.sender, SWORD, 1000, "");
_mint(msg.sender, SHIELD, 500, "");
_mint(msg.sender, POTION, 10000, "");
}
function craftItem(uint256 itemId) external {
// Example: Craft a sword using gold and silver
if (itemId == SWORD) {
_burn(msg.sender, GOLD, 100 * 10**18);
_burn(msg.sender, SILVER, 50 * 10**18);
_mint(msg.sender, SWORD, 1, "");
}
}
}
4.5 Smart Contract Data Structures
Efficient data structures are critical for gas optimization and cross-chain compatibility.
Storage Optimization Patterns
// BAD: Wastes storage slots
struct UserData {
bool isActive; // 1 byte, wastes 31 bytes
uint256 balance; // 32 bytes
address wallet; // 20 bytes, wastes 12 bytes
uint8 level; // 1 byte, wastes 31 bytes
}
// GOOD: Packs into fewer slots
struct UserDataOptimized {
address wallet; // 20 bytes
uint96 balance; // 12 bytes (supports up to 79B tokens)
// ↑ Slot 1: 32 bytes total
bool isActive; // 1 byte
uint8 level; // 1 byte
uint240 reserved; // 30 bytes reserved for future use
// ↑ Slot 2: 32 bytes total
}
// SAVINGS: 4 slots → 2 slots = 50% storage cost reduction
Event-Driven Architecture
Minimize on-chain storage by using events for historical data:
contract EfficientLedger {
// Only store current state
mapping(address => uint256) public balances;
// Emit events for historical record
event Deposit(address indexed user, uint256 amount, uint256 timestamp);
event Withdrawal(address indexed user, uint256 amount, uint256 timestamp);
function deposit() external payable {
balances[msg.sender] += msg.value;
emit Deposit(msg.sender, msg.value, block.timestamp);
}
// Off-chain indexers can reconstruct full history from events
// On-chain storage only tracks current balances
}
4.6 Validation Rules and Type System
WIA defines strict validation rules to ensure data integrity across chains.
Address Validation
| Chain | Format | Length | Example |
|---|---|---|---|
| Ethereum/EVM | Hex (0x prefix) | 42 chars | 0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb |
| Bitcoin | Base58 | 26-35 chars | 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa |
| Solana | Base58 | 44 chars | 7EqQdEUX7FqWfqvB8xUq2Sd8YvNqKvqRfBr4DqVWqvVn |
| Cosmos | Bech32 | 45 chars | cosmos1sj2qfq3p7j52qfq3p7j52qfq3p7j52qfq8n6jz |
Amount Validation
// Amount Validation Rules
{
"amount": {
"type": "string",
"pattern": "^[0-9]+$",
"description": "Integer string in base units (e.g., wei for ETH)",
"validation": {
"minValue": "0",
"maxValue": "2^256 - 1",
"decimals": "Must match token decimals"
}
},
"amountFormatted": {
"type": "string",
"pattern": "^[0-9]+\\.[0-9]+$",
"description": "Human-readable amount with decimals",
"example": "1000.50"
}
}
4.7 Encoding and Serialization Standards
Efficient encoding is critical for cross-chain data transmission.
Supported Encodings
| Encoding | Use Case | Efficiency | Chains |
|---|---|---|---|
| ABI Encoding | Ethereum smart contract calls | Medium | EVM chains |
| RLP | Ethereum transactions | High | Ethereum |
| Borsh | Solana programs | Very High | Solana, NEAR |
| Protocol Buffers | Cosmos SDK chains | Very High | Cosmos ecosystem |
| JSON (WIA Standard) | Cross-chain messaging, APIs | Low (human-readable) | Universal |
4.8 Real-World Implementation Example
Let's see how all these components work together in a complete example.
// Complete WIA-20 Stablecoin Implementation
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
import "./WIA20Base.sol";
contract WIAStablecoin is WIA20Base {
address public treasury;
uint256 public constant MAX_SUPPLY = 1000000000 * 10**6; // 1B USDC
mapping(address => bool) public blacklisted;
event Blacklisted(address indexed account);
event RemovedFromBlacklist(address indexed account);
event Minted(address indexed to, uint256 amount);
event Burned(address indexed from, uint256 amount);
constructor() WIA20Base("WIA USD Coin", "wUSDC", 6) {
treasury = msg.sender;
// Set metadata
setMetadata(
'{"website":"https://wia.finance","logo":"ipfs://QmLogo123"}'
);
// Register on multiple chains
_registerChainRepresentation(1, address(this)); // Ethereum
_registerChainRepresentation(137, 0x2791Bca1f2de4661ED88A30C99A7a9449Aa84174); // Polygon
_registerChainRepresentation(56, 0x8AC76a51cc950d9822D68b83fE1Ad97B32Cd580d); // BSC
}
function mint(address to, uint256 amount) external onlyRole(DEFAULT_ADMIN_ROLE) {
require(totalSupply() + amount <= MAX_SUPPLY, "Exceeds max supply");
_mint(to, amount);
emit Minted(to, amount);
}
function burn(uint256 amount) external {
_burn(msg.sender, amount);
emit Burned(msg.sender, amount);
}
function blacklist(address account) external onlyRole(COMPLIANCE_ROLE) {
blacklisted[account] = true;
emit Blacklisted(account);
}
function removeFromBlacklist(address account) external onlyRole(COMPLIANCE_ROLE) {
blacklisted[account] = false;
emit RemovedFromBlacklist(account);
}
function isTransferCompliant(
address from,
address to,
uint256 amount
) public view override returns (bool) {
return !blacklisted[from] && !blacklisted[to];
}
}
Chapter Summary: 5 Key Takeaways
- Universal Transaction Schema provides a chain-agnostic format for representing any blockchain transaction with comprehensive metadata, enabling cross-chain tracking and interoperability.
- WIA-20, WIA-721, and WIA-1155 extend ERC standards with 100% backward compatibility while adding cross-chain transfers, enhanced metadata, compliance hooks, and batch operations.
- Gas optimization is built into the standard through storage packing, event-driven architecture, batch operations, and efficient data structures, reducing costs by 40-60% compared to naive implementations.
- Comprehensive metadata schemas enable rich applications including royalty payments, fractionalization, rental mechanisms, compliance integration, and provenance tracking—all standardized for interoperability.
- Strict validation rules and multiple encoding formats ensure data integrity across chains while supporting native formats (ABI, RLP, Borsh, Protobuf) plus universal JSON for maximum compatibility.
Review Questions
- What are the five required fields in the WIA Universal Transaction Schema and why is each necessary?
Answer: (1) version—ensures schema compatibility; (2) id—unique identifier for tracking; (3) type—categorizes transaction for indexing; (4) source—identifies origin chain and sender; (5) status—tracks transaction state. These enable universal transaction representation across all chains. - How does WIA-20 maintain 100% backward compatibility with ERC-20 while adding new features?
Answer: WIA-20 extends the IERC20 interface rather than replacing it, implementing all standard functions (transfer, approve, balanceOf, etc.) exactly as specified. New features like crossChainTransfer and metadata are added as optional functions that don't affect existing ERC-20 functionality. - Explain the storage optimization technique shown in the UserDataOptimized struct and calculate the gas savings.
Answer: The optimization packs multiple variables into single 32-byte storage slots. address (20 bytes) + uint96 (12 bytes) = 32 bytes (slot 1); bool (1 byte) + uint8 (1 byte) + uint240 (30 bytes) = 32 bytes (slot 2). This uses 2 slots instead of 4, saving 2 SSTORE operations × ~20,000 gas = ~40,000 gas per struct initialization. - What are the five key enhancements that WIA-721 adds beyond standard ERC-721?
Answer: (1) Cross-chain transfers between blockchains; (2) Built-in royalty standard ensuring creator payments; (3) Fractionalization support for dividing NFT ownership; (4) Optional on-chain metadata for permanence; (5) Rental standard allowing temporary usage without ownership transfer. - Why does the WIA standard use both base unit amounts (string) and formatted amounts (string) in the transaction schema?
Answer: Base unit amounts (e.g., "1000000000" wei) ensure precision without floating-point errors and match smart contract representations. Formatted amounts (e.g., "1000.00") provide human-readable values. Using strings prevents JavaScript number precision issues with large integers (2^53 limit). - Describe how the event-driven architecture pattern reduces gas costs and provide a concrete example.
Answer: Events cost ~375 gas per log vs. ~20,000 gas for SSTORE. Instead of storing transaction history on-chain (expensive), contracts emit events that off-chain indexers capture. Example: A contract storing 10,000 historical transactions on-chain would cost 200M gas; emitting events costs only 3.75M gas—a 98% reduction. Current state stays on-chain, history lives in events.
Looking Ahead: Chapter 5
With the data format foundation established, we'll explore Phase 2: Interoperability Layer in Chapter 5. Topics include:
- The WIA Universal Bridge Protocol architecture and security model
- Multi-signature validator networks and consensus mechanisms
- Asset mapping and liquidity pools for efficient cross-chain swaps
- Proof verification methods (merkle proofs, validator signatures, state proofs)
- Bridge security best practices and attack prevention
- Performance optimization for fast cross-chain transfers
- Real-world bridge implementation with code examples
You'll learn how Phase 1's data formats enable Phase 2's secure cross-chain asset transfers, completing the technical foundation for a truly interoperable blockchain finance ecosystem.