@deadrosesxyz I have no context, but the date when he sold is what matters in my opinion, not the date of his announcement.
Anyway, I guess @ParlayItGG will have clear rules :D
I spent this week learning Soroban.
I read all their docs so you don't have to :D
Below is a list with some standout differences between EVM and Stellar and of course, Solidity vs Soroban that I hope you'll find valuable:
• An EOA (Classic Accounts) can bundle 100 Operations in a transaction, but a transaction executing a smart contract (InvokeHostFunctionOp) is strictly capped at exactly one operation. It's like having "multicall" implemented at the protocol level for classic accounts, but smart contract invocations lose this capability.
• Host vs. Guest: The "Host" is the underlying Rust-based validator managing hardware and consensus, while the "Guest" is the isolated WebAssembly sandbox where your contract runs.
• The smallest base unit of the network token (XLM) is called a stroop, which equals 0.0000001 XLM or 10^-7.
• Classic Accounts must maintain a minimum balance tied to a "base reserve" in order to exist. The current base reserve is (0.5 XLM), and each EOA must hold 2x base reserve (1 XLM). Dropping below 1 XLM results in account deletion.
• State Costs Native Tokens: Classic Accounts use "subentries" to store data. Every single subentry requires the user to lock 1x base reserve (0.5 XLM) of the user's funds permanently, up to a hard cap of 1,000 subentries. If Alice wants to own USDC, she must hold 1.5 XLM on her account instead of 1, in order for it not to be deleted.
• Stellar Asset Contracts (SAC) are built-in tokens at the protocol level. Think USDC, but natively supported.
• The DoS Protection (Trustlines): To prevent attackers from DoSing Classic wallets via worthless SAC token airdrops that spawn subentries and lock up XLM, Stellar Classic Assets require explicit opt-in "Trustlines". You can't simply transfer these assets to a user's EOA. They must "opt in".
• Wasm Token Contracts: Pure Soroban Wasm tokens abandon this lockup model. The transaction caller pays the storage rent, meaning a sender can force-feed tokens into a receiver's wallet without consent, exactly like the EVM. A bit confusing, I know. You have two types of tokens, basically.
• Smart Contract Existence: Soroban contracts (C... addresses) bypass classic minimum balance requirements and operate on a dynamically metered I/O rent model paid by the transaction caller.
• The Stellar ledger is a global key-value store where state is decoupled from the contract address.
• Isolated Data: Code, contract instance configuration, and persistent data are all stored as completely independent LedgerEntry records in the global database.
• No Guest Serialization: The Wasm environment contains no serialization code; the native Rust Host validates and serializes all XDR object types across the boundary.
• The Primary Gas Limit: the transaction constraint is Ledger I/O storage access fees.
• I/O Gas Exhaustion: Using unbounded Vec or Map containers for protocol data forces the Host to deserialize the entire structure on every call, leading to O(N) Gas Exhaustion and permanently bricking the contract.
• No Free Storage: Permanent free state does not exist. If you do not pay rent to extend the Time-To-Live (TTL), the contract's state is either permanently deleted (if storage was Temporary) or archived (if the storage type was either Persistent or Instance).
• If storage is archived, it can be restored, except for Temporary storage, which gets permanently deleted from the ledger.
• Anyone can extend the lifetime of the storage. Calling extend_ttl() can be done by anyone and operates on comparative thresholds with no access controls.
• The Wasm bytecode executable has an independent TTL from the contract instance data. If the code entry archives, the contract panics on invocation, even if the contract instance data remains valid. Calling https://t.co/D0OLoqDmNN().instance().extend_ttl() safely bumps both simultaneously, but only bumping persistent data will allow the Wasm code to silently expire.
• No msg.sender: Soroban replaces msg.sender with Call-Stack Adjacency Validation and decoupled Auth Trees. Too complex to explain in a bullet point.
• Implicit Trust Limits: If User -> Contract A -> Contract B, Contract B implicitly trusts Contract A because they are adjacent. The trust boundary terminates immediately at B; Contract C will reject Contract A.
• Auth Trees for Deep Calls: To execute non-adjacent cross-contract calls safely (see the above point), intermediate contracts must publish an InvokerContractAuthEntry tree via authorize_as_current_contract. A bit too complex for a bullet point to dive further.
• Invoking external contracts using standard invoke_contract will "hard" revert, while using the try_invoke_contract will handle the revert gracefully.
• Reentrancy is blocked: Standard single-contract reentrancy is impossible because the Host blocks it, but cross-contract reentrancy is possible.
• If a protocol manually locks state across contracts and fails to use Rust's Drop trait on an Err match, the protocol may remain permanently stuck. This is important in the context of implementing a ReentrancyGuard like functionality.
• Precision Loss and Overflows: Soroban panics on overflow by default, but is limited to 128-bit math. Protocols utilizing high-precision multipliers (like ray math) should cast i128 balances to u128 prior to scaling.
• No Contract checks. Because the Address type is cryptographically opaque to the Guest, tx.origin or is_contract() checks are impossible to implement.
• Flash Loans are Single-Op: Flash loans execute entirely within a single InvokeHostFunctionOp execution stack; they do not require multiple operations.
• Multi-sig Admin Freeze: The Host evaluates signatures against the account's "Medium" threshold. Altering that threshold to an unreachable value freezes the contract forever. Think of EOAs as having native Multisig capabilities built-in at the protocol layer. If you mess up your signing thresholds, your EOA will be locked forever, so don't be an idiot.
• "Storage Collisions" on Upgrade: When updating a contract's Wasm binary, redefining the data types bound to an existing DataKey enum variant will break Host deserialization, corrupting legacy data.
• Signature verifications: Granular authorization via require_auth_for_args() is dangerous if implemented lazily. Omitting safety checks allows attackers to intercept the payload and execute it with stolen parameters.
I listened to this, and I recommend it. What @Ehsan1579 is doing is crazy.
I suspected he was doing it with AI since October last year, lol, but he just confirmed it. Also, I noticed how he kept saying "we, we, we" so he is not a "1 man army" hunting 24/7 like a madman. That's how he started, but nowadays, there seems to be a team involved.
Either way, congrats on your achievements and gj Mitchell for the interview!
@paulg@Austen It's a stupid bet :D
Google can copy-cat them faster than they can innovate. Besides, Gemini is like a sleeper. I'd argue 3.1 Pro is on par with the other flagship models; it's just that Google doesn't do such good marketing for their models.