ethskills

To enable efficient offchain querying, every state change in your smart contract should emit a Solidity event. Events are the primary way indexers, frontends, and block explorers track historical activity.

Best Practices:

• Index searchable fields: Use the indexed keyword for fields you will frequently filter by (e.g., address, id, owner). You are limited to 3 indexed topics per event.
• Avoid indexing large values: Do not index data that you won't use for filtering to save gas.
• Use events for history: Do not rely on eth_call for historical state; use events to reconstruct history offchain.

// ✅ Good — every action emits a queryable event
contract Marketplace {
    event Listed(
        uint256 indexed listingId,
        address indexed seller,
        address indexed tokenContract,
        uint256 tokenId,
        uint256 price
    );
    event Sold(uint256 indexed listingId, address indexed buyer, uint256 price);
    event Cancelled(uint256 indexed listingId);

    function list(address token, uint256 tokenId, uint256 price) external {
        uint256 id = nextListingId++;
        listings[id] = Listing(msg.sender, token, tokenId, price, true);
        emit Listed(id, msg.sender, token, tokenId, price);
    }

    function buy(uint256 listingId) external payable {
        // ... transfer logic ...
        emit Sold(listingId, msg.sender, msg.value);
    }
}

When designing or reviewing dApps, avoid these common misconceptions that undermine the CROPS pillars:

• "It works" is not enough: A functional dApp can still be broken if it relies on a censorable frontend, closed indexer, invisible RPC, or custodial wallet.
• Decentralization is more than just contracts: A permissionless contract does not make a dApp decentralized if the user experience depends on a single hosted frontend, API, relayer, paymaster, sequencer, bridge, or wallet vendor.
• Verified contracts $ eq$ Open dApp: Etherscan verification only ties bytecode to source for that specific contract. An "Open" dApp requires the whole stack to be public, and "Free" requires OSI-permissive or copyleft licenses (not just source-available).
• Privacy must be architected early: Do not wait until after the architecture is set to check privacy. Evaluate exposure of addresses, balances, counterparties, timing data, IP metadata, and wallet fingerprints during the design phase.
• Security is more than code bugs: Beyond reentrancy and oracle manipulation, you must account for custody, upgrades, admin keys, recovery, emergency powers, and vendor liveness (whether the app works if the team disappears).
• List trust tradeoffs for all options: When presenting architecture choices (e.g., Embedded Wallet vs. Safe vs. EOA, or Vercel vs. IPFS), explicitly label the CROPS impact and recommend the most CROPS-aligned default.

You can combine ERC-8004 (Identity) and x402 (Payments) to create a fully autonomous economic loop for agents. This allows agents to discover services, verify reputation, pay for access, and provide feedback without human intervention.

The Autonomous Loop:

1. Discovery: Agent finds a service via the ERC-8004 registry.
2. Verification: Agent checks the service's reputation via ERC-8004.
3. Request: Agent calls the service endpoint.
4. Payment: Service returns 402 Payment Required; Agent pays via x402 (using an EIP-3009 signature).
5. Execution: Agent receives the requested service.
6. Feedback: Agent posts reputation feedback to ERC-8004.

1. Agent discovers service (ERC-8004 registry)
2. Agent checks reputation (ERC-8004)
3. Agent calls endpoint → 402 Payment Required
4. Agent pays via x402 (EIP-3009 signature)
5. Agent receives service
6. Agent posts feedback to ERC-8004

To ensure a scalable and secure dApp, avoid these common mistakes:

• Kitchen sink contract: Avoid creating one massive contract that handles everything (swap, lend, stake, etc.). Split responsibilities into multiple specialized contracts.
• Factory nobody asked for: Do not build a factory contract unless your protocol actually requires deploying multiple unique instances for different users.
• Onchain everything: Only store ownership and value transfers onchain. Use offchain storage for user profiles, activity logs, images, and analytics.
• Admin crutch: Avoid relying on a single admin account for maintenance. Design permissionless alternatives with proper incentives.
• Premature multi-chain: Do not launch on multiple chains simultaneously. Prove product-market fit on one chain first.
• Reinventing audited primitives: Do not write your own ERC-20, access control, or math libraries. Always use battle-tested libraries like OpenZeppelin.
• Ignoring the frontend: A working contract with a broken UI is useless. Budget approximately 40% of your development time for frontend polish.

Ethereum protocol changes follow a specific lifecycle from proposal to implementation. Understanding these states is critical for determining how close a feature is to being live.

EIP Lifecycle (Specification Phase)

• Draft: Initial written proposal; no indication of likelihood of inclusion.
• Review: The proposal is under discussion.
• Last Call: The specification is frozen; this is the final period for objections.
• Final: The specification is complete. For non-fork EIPs (like ERCs), it is official. For fork EIPs, it is ready but not yet scheduled.

Fork Inclusion States (Implementation Phase)

• CFI (Considered for Inclusion): Core devs are evaluating the EIP for a specific fork; implementation work has begun.
• SFI (Scheduled for Inclusion): The EIP is confirmed for a fork and is being tested on devnets.
• DFI (Declined for Inclusion): The EIP was rejected for a specific fork but may be reconsidered later.

Draft → Review → Last Call → Final
                    ↓
            (for hard forks)
         CFI → SFI → Included

Robinhood Chain (Chain ID 4663) is an Arbitrum Orbit rollup that settles directly to Ethereum (not an L3). It uses Ethereum blob DA and ETH for gas.

Stock Token Mechanics:

• Tokens are plain ERC-20s (18 decimals) representing economic exposure to debt securities.
• Not available to US, Canada, UK, Switzerland, or UAE persons.
• Uses a Blocklist (not allowlist) via a shared AccessControlsRegistry.
• Implements ERC-8056 "Scaled UI Amount" for handling splits/dividends via a uiMultiplier() display; raw balances do not rebase.
• USDG (Paxos) stablecoin uses 6 decimals, not 18.

⚠️ Critical Censorship Warning: Robinhood Chain uses ArbOS 61 transaction filtering. An authorized filterer can register any tx hash in a precompile (0x…0074), causing the state transition function to reject it—even if the transaction was force-included via L1. Force inclusion is NOT a censorship escape hatch here. Run crops/SKILL.md before building censorship-sensitive applications.