Lesson 17: XLS-101 Smart Contracts - The Next Generation

From the XLS-101d specification:

XLS-101 DESIGN GOALS

1. PERMISSIONLESS DEPLOYMENT

1. NATIVE INTEGRATION

1. DEVELOPER EXPERIENCE

1. XRPL SECURITY PHILOSOPHY

XLS-101 IS NOT:

✗ A clone of Ethereum's EVM
  → Different execution model

✗ Turing-complete
  → Still bounded computation

✗ Production-ready
  → In proposal/development stage

✗ A replacement for Hooks
  → May coexist

✗ Guaranteed to be implemented
  → Requires amendment approval

---

HOOKS EXECUTION:
├── Trigger: Transaction affects account
├── Location: Code attached to account
├── Entry: hook() and cbak() functions
├── Control: Accept/Rollback transaction
└── Relationship: Guard for account

XLS-101 EXECUTION:
├── Trigger: ContractCall transaction
├── Location: Code on pseudo-account
├── Entry: Named functions
├── Control: Return values
└── Relationship: Independent contract entity
```

Hooks:

User Account (rAddress)
├── XRP Balance
├── Trust Lines
├── Owned Objects
└── Hook Attached ← Code lives here

XLS-101:

Contract Pseudo-Account
├── Code
├── Contract Storage
├── Contract Balance
└── Not a regular account (no keys)

User Account
├── Interacts via ContractCall
└── Pays fees for execution
```

Hooks:

// Implicit invocation
// User sends payment to Hook account
// Hook fires automatically

// hook() runs
// No direct calling of hook() possible
```

XLS-101:

// Explicit invocation
// User sends ContractCall transaction

ContractCall {
Account: "rUserAddress",
Contract: "rContractAddress",
Function: "transfer",
Arguments: [to, amount]
}

// Named function executes
// Return value available
```

---

// Hypothetical XLS-101 contract structure

// State variables
storage {
owner: AccountID,
balance: Amount,
paused: Bool
}

// Functions
function initialize(initial_owner: AccountID) {
require(storage.owner == ZERO_ACCOUNT);
storage.owner = initial_owner;
}

function transfer(to: AccountID, amount: Amount) returns Bool {
require(!storage.paused);
require(amount <= storage.balance);

storage.balance -= amount;
emit_payment(to, amount);

return true;
}

function pause() {
require(caller == storage.owner);
storage.paused = true;
}
```

{
    "TransactionType": "ContractCall",
    "Account": "rUserAccount...",
    "ContractID": "rContractAddress...",
    "Function": "transfer",
    "Arguments": [
        {"type": "AccountID", "value": "rRecipient..."},
        {"type": "Amount", "value": "1000000"}
    ],
    "Fee": "12",
    "Sequence": 42
}

Hooks:

// Namespace-based, key-value
state(SBUF(value), SBUF("mykey"));
state_set(SBUF(new_value), SBUF("mykey"));
// Keys up to 32 bytes, values up to 256 bytes

XLS-101 (Proposed):

// Contract storage model
storage.balance = 100;
storage.users[address] = UserInfo{...};
// More structured, potentially larger

Hooks:

// Limited composability
// Hook A cannot call Hook B directly
// Only through emissions (next ledger)

XLS-101 (Proposed):

// Contract-to-contract calls
function use_other_contract() {
    result = call(other_contract, "get_price", [token]);
    // Synchronous result (same transaction)
}

---

FEATURE                    HOOKS        XLS-101
──────────────────────────────────────────────────
Permissionless deploy      ✗ (needs acct)  ✓
Direct function calls      ✗              ✓
Named entry points         ✗ (hook/cbak)  ✓
Contract-to-contract       ✗              ✓ (proposed)
Transaction filtering      ✓              ✗ (different)
Account guard role         ✓              ✗
Return values to caller    ✗              ✓
Structured storage         Limited        ✓
WebAssembly execution      ✓              ✓
Bounded computation        ✓              ✓
Live on mainnet           ✗              ✗
Live on Xahau              ✓              ✗

USE CASE                   BETTER FIT
──────────────────────────────────────────────────
Payment filtering          Hooks
Auto-forward payments      Hooks
General DeFi               XLS-101
Complex AMM logic          XLS-101
NFT marketplace            XLS-101
Simple escrow              Either
Multi-party agreements     XLS-101
Account protection         Hooks
Gaming/collectibles        XLS-101

DEVELOPER EXPERIENCE COMPARISON

HOOKS:
├── Language: C
├── Compilation: C → WASM
├── Debugging: trace() logging
├── Patterns: Low-level, manual
├── Learning curve: Steep
└── Tooling: Basic

XLS-101 (Expected):
├── Language: TBD (possibly multiple)
├── Compilation: Higher-level → WASM
├── Debugging: Better tooling expected
├── Patterns: More familiar (EVM-like)
├── Learning curve: Moderate
└── Tooling: In development
```

---

XLS-101 TIMELINE

July 2024:
├── XLS-101d specification published
└── Initial proposal

Late 2024:
├── AlphaNet deployment
├── Early testing
└── Community feedback

2025:
├── Continued development
├── Specification refinement
├── Tooling development
└── NO mainnet deployment yet

Future (Unknown):
├── DevNet/TestNet
├── Amendment proposal
├── Validator voting
└── Mainnet activation
```

AVAILABLE NOW:
✓ Specification document (XLS-101d)
✓ AlphaNet for testing
✓ GitHub discussions
✓ Developer previews

NOT AVAILABLE:
✗ Production deployment
✗ Stable tooling
✗ Final specification
✗ Mainnet timeline
```

REALISTIC EXPECTATIONS

Q: When will XLS-101 be on mainnet?
A: Unknown. Multi-year timeline likely.

Q: Should I wait for XLS-101 instead of learning Hooks?
A: No. Hooks are available now (Xahau).
XLS-101 may take years. Learn Hooks,
concepts will transfer.

Q: Will XLS-101 replace Hooks?
A: Possibly coexist. Hooks better for some
use cases. Both may be available.

Q: Is XLS-101 guaranteed?
A: No. Requires amendment approval.
Community/validator support needed.
```

---

Skills from Hooks that apply to XLS-101:

TRANSFERABLE:
✓ WebAssembly understanding
✓ Bounded computation mindset
✓ XRPL native features knowledge
✓ State management patterns
✓ Security thinking
✓ Transaction model understanding

WILL CHANGE:
├── Invocation patterns
├── Specific API functions
├── Code structure
├── Deployment process
└── Tooling

POTENTIAL MIGRATION PATH

TRACKING XLS-101 PROGRESS

Official Sources:
├── GitHub: XRPL-Standards repository
├── XLS-101 discussion thread
├── XRPL Dev blog updates
└── RippleX announcements

Community:
├── XRPL Discord
├── Developer forums
├── Twitter/X updates
└── Conference presentations
```

---

#include "hookapi.h"

int64_t hook(uint32_t reserved) {
_g(1, 1);

// Read counter
uint8_t counter_buf[8];
int64_t len = state(SBUF(counter_buf), SBUF("counter"));
int64_t counter = (len == 8) ? INT64_FROM_BUF(counter_buf) : 0;

// Increment
counter++;

// Write counter
INT64_TO_BUF(counter_buf, counter);
state_set(SBUF(counter_buf), SBUF("counter"));

accept(SBUF("Counted"), 0);
return 0;
}

int64_t cbak(uint32_t r) { return 0; }
```

// Hypothetical XLS-101 syntax (not final)

contract Counter {
storage {
count: Int64
}

function initialize() {
storage.count = 0;
}

function increment() returns Int64 {
storage.count += 1;
return storage.count;
}

function get_count() view returns Int64 {
return storage.count;
}
}
```

HOOKS:
├── Triggered by any transaction to account
├── Must read state with explicit key
├── Must serialize integers manually
├── Returns via accept/rollback message
└── Counter increments on any tx to account

XLS-101 (Hypothetical):
├── Triggered by explicit increment() call
├── State accessed via typed storage
├── Type system handles serialization
├── Returns value to caller
└── Counter only increments on increment call
```

---

✅ XLS-101 is a serious proposal. Active development, published spec, AlphaNet deployment.

✅ It addresses Hooks limitations. More flexible invocation, better composability.

✅ XRPL community is invested. Significant resources allocated to development.

⚠️ Final specification. Details may change significantly.

⚠️ Timeline to mainnet. No confirmed date, likely years away.

⚠️ Relationship with Hooks. Coexistence vs replacement unclear.

⚠️ Validator support. Amendment requires 80%+ approval.

🔴 Waiting instead of building. XLS-101 may take years; Hooks are available now.

🔴 Assuming XLS-101 details. Specification is not final.

🔴 Ignoring Hooks entirely. Hooks concepts transfer; learning them is valuable.

XLS-101 represents an evolution in XRPL programmability with more flexible, developer-friendly patterns. But it's not production-ready and timeline is uncertain. Learn Hooks now—the concepts transfer. Follow XLS-101 development but don't wait for it if you have current needs.

---

Assignment: Analyze how a specific use case would be implemented in Hooks vs XLS-101.

Requirements:

• Token vesting schedule

• NFT auction

• Escrow with conditions

• Lending pool

• State schema

• Trigger conditions

• Core logic flow

• Limitations identified

• Contract structure

• Function definitions

• State model

• Expected advantages

• Which is better suited and why

• Specific trade-offs

• Migration considerations

• Recommendation

• How to design for potential migration

• What to abstract

• Risk assessment

• Hooks design quality (25%)

• XLS-101 understanding (25%)

• Comparison depth (25%)

• Practical recommendations (25%)

Time investment: 3-4 hours
Value: Strategic thinking about XRPL programmability evolution

---

For Next Lesson:
We'll explore the XRPL EVM Sidechain—a production-ready alternative for smart contracts today.

---

End of Lesson 17

Total words: ~4,100
Estimated completion time: 55 minutes reading + 3-4 hours for deliverable