Lesson 20: Course Summary and Reference Guide

// CONTROL
accept(SBUF(msg), code);      // Accept transaction
rollback(SBUF(msg), code);    // Reject transaction
trace(SBUF(msg), num);        // Debug output
GUARD(n)                       // Loop guard (max n iterations)

// TRANSACTION
otxn_type(); // Get transaction type
otxn_amount(); // Get XRP amount (drops)
otxn_field(SBUF(buf), sfCode); // Get field value
otxn_id(SBUF(buf), 0); // Get transaction hash
otxn_param(SBUF(buf), SBUF(name)); // Get Hook parameter

// STATE
state(SBUF(buf), SBUF(key)); // Read state
state_set(SBUF(buf), SBUF(key)); // Write state
state_set(0, 0, SBUF(key)); // Delete state

// LEDGER
ledger_seq(); // Current ledger number
util_keylet(SBUF(k), type, params...); // Generate keylet
slot_set(SBUF(keylet), slot); // Load object
slot_subfield(slot, sfCode, new_slot); // Read field

// EMISSION
etxn_reserve(count); // Reserve slots
PREPARE_PAYMENT_SIMPLE(buf, amt, dest, dtag, stag);
emit(SBUF(hash), SBUF(tx)); // Emit transaction
```

// Transaction fields
sfAccount           // Sender (20 bytes)
sfDestination       // Recipient (20 bytes)
sfAmount            // Amount (8 or 48 bytes)
sfFee               // Fee (8 bytes)
sfSequence          // Sequence (4 bytes)
sfMemos             // Memos array
sfDestinationTag    // Dest tag (4 bytes)
sfSourceTag         // Source tag (4 bytes)
sfTransactionType   // Type (2 bytes)

// Account fields
sfBalance // XRP balance
sfOwnerCount // Owned objects
sfFlags // Account flags
```

uint8_t account_id[20];     // Account IDs
uint8_t hash[32];           // All hashes
uint8_t keylet[34];         // Keylets
uint8_t xrp_amount[8];      // XRP amounts
uint8_t iou_amount[48];     // IOU amounts
uint8_t state_key[32];      // State keys (max)
uint8_t state_value[256];   // State values (max)

// 64-bit integer to/from buffer
INT64_TO_BUF(buf, value);
int64_t val = INT64_FROM_BUF(buf);

// 32-bit unsigned to/from buffer
UINT32_TO_BUF(buf, value);
uint32_t val = UINT32_FROM_BUF(buf);
```

---

// Check if sender is whitelisted
uint8_t whitelist[3][20] = { /* addresses */ };

int is_whitelisted(uint8_t* account) {
for (int i = 0; GUARD(3), i < 3; ++i) {
int match = 1;
for (int j = 0; GUARD(60), j < 20; ++j) {
if (whitelist[i][j] != account[j]) {
match = 0;
break;
}
}
if (match) return 1;
}
return 0;
}
```

// Increment and store counter
uint8_t buf[8];
uint8_t key[] = "counter";
int64_t len = state(SBUF(buf), SBUF(key));
int64_t count = (len == 8) ? INT64_FROM_BUF(buf) : 0;
count++;
INT64_TO_BUF(buf, count);
state_set(SBUF(buf), SBUF(key));

// Forward payment to another address
if (otxn_type() == 0 && otxn_amount() > 0) {
    uint8_t forward[20] = { /* dest */ };
    etxn_reserve(1);
    uint8_t tx[PREPARE_PAYMENT_SIMPLE_SIZE];
    PREPARE_PAYMENT_SIMPLE(tx, otxn_amount(), forward, 0, 0);
    uint8_t hash[32];
    emit(SBUF(hash), SBUF(tx));
}

// Get account's available balance
int64_t get_available(uint8_t* account) {
    uint8_t keylet[34];
    util_keylet(SBUF(keylet), KEYLET_ACCOUNT,
                (uint32_t)account, 20, 0, 0, 0, 0);
    if (slot_set(SBUF(keylet), 1) < 0) return 0;

int64_t balance = slot_subfield(1, sfBalance, 0);
int64_t owner_count = slot_subfield(1, sfOwnerCount, 0);
int64_t reserve = 10000000 + (owner_count * 2000000);
return balance - reserve;
}
```

---

Q: "undefined reference to 'function'"

A: The function isn't in Hooks API. Check xrpl-hooks.readme.io
   for valid functions. Standard C library not available.

Q: "guard required"

A: All loops need GUARD(n). Add before loop condition:
   for (int i = 0; GUARD(10), i < 10; ++i)

Q: "memory allocation not allowed"

A: No heap. Use stack arrays only:
   uint8_t buf[32];  // OK
   malloc(32);       // NOT OK

Q: "tecHOOK_REJECTED"

A: Hook binary invalid. Check:
   - Compilation actually succeeded
   - No warnings ignored
   - Run guard-checker

Q: Hook doesn't seem to fire

A: Check:
   - Sending TO Hook account (incoming trigger)
   - Hook deployed to correct account
   - HookOn filter allows transaction type
   - View account in explorer for Hook status

Q: Guard violation rollback

A: Loop exceeded guard limit:
   - Increase guard value
   - Check loop termination condition
   - Verify counter increments correctly

Q: State not persisting

A: Ensure:
   - accept() called (not rollback)
   - state_set returned positive
   - Correct key used
   - Value size within 256 bytes

Q: Emission failing

A: Check:
   - etxn_reserve() called first
   - Sufficient balance for amount + fees
   - Valid destination account
   - emit() return value

Q: When will Hooks be on XRPL mainnet?

A: Unknown. Requires validator amendment (80%+ for 2 weeks).
   No confirmed timeline. Could be 2026, 2028, or later.

Q: Should I use Xahau or EVM Sidechain?

A: Depends on use case:
   - Transaction filtering/guarding → Xahau/Hooks
   - Complex DeFi/composability → EVM Sidechain
   - Must use XAH → Xahau
   - Must use XRP → EVM Sidechain (bridged)

Q: Is XLS-101 ready?

A: No. In development with AlphaNet. Not production-ready.
   Multi-year timeline expected.

---

□ Code compiles without warnings
□ All guards present and correct
□ All return values checked
□ Buffer sizes correct
□ Integer overflow handled
□ State initialized properly
□ Emissions reserved before emit
□ Tested on testnet
□ Edge cases verified
□ Documentation complete

□ Input validation on all fields
□ No unchecked otxn_field calls
□ Negative amounts handled (IOUs)
□ State existence checked
□ Integer arithmetic safe
□ Emission amounts validated
□ Recipients validated
□ Balance checked before emissions
□ Default to rejection pattern
□ Code reviewed by another developer

□ Thorough testnet testing
□ Security audit completed
□ Documentation published
□ Monitoring set up
□ Failure handling tested
□ Callback implemented
□ State schema documented
□ Configuration documented
□ Update plan established
□ Support process defined

---

AFTER THIS COURSE:

1. BUILD A PROJECT

1. DEEPEN KNOWLEDGE

1. ENGAGE COMMUNITY

ADVANCED LEARNING:

Technical:
├── WebAssembly deep dive
├── XRPL protocol internals
├── Advanced C patterns
└── Security auditing

Ecosystem:
├── Track XLS-101 development
├── Monitor Hooks mainnet progress
├── Follow EVM Sidechain growth
└── Watch for new proposals

Practical:
├── Build increasingly complex Hooks
├── Contribute to open source
├── Create tools and libraries
└── Write tutorials

XRPL DEVELOPMENT OPPORTUNITIES:

Roles:
├── Hook/Smart Contract Developer
├── XRPL Protocol Engineer
├── DeFi Developer
├── Security Auditor
├── Technical Writer
└── Developer Relations

Where:
├── Ripple
├── XRPL ecosystem companies
├── DeFi protocols
├── Consulting
├── Freelance
└── Your own projects

---

You now understand:

1. Why XRPL chose constraints over full programmability
2. How Hooks work at a technical level
3. How to write, deploy, and test Hooks
4. Security and optimization best practices
5. The broader XRPL programmability landscape
6. Strategic thinking about platform choices

PRINCIPLES TO REMEMBER:

1. Correctness > Performance

1. Security > Features

1. Simplicity > Cleverness

1. Testing > Hoping

1. Documentation > Memory

1. Community > Isolation

XRPL programmability is real and growing. You have the skills to build meaningful applications today—on Xahau with Hooks or on the EVM Sidechain with Solidity. Native XRPL mainnet programmability is coming, though the timeline is uncertain. The fundamentals you've learned transfer across platforms.

The best strategy: Build now, learn continuously, stay flexible.

---

Congratulations on completing Hooks & Smart Contracts - Advanced XRPL Programming!

• XRPL programmability philosophy and architecture

• Hook development in C

• State management and emissions

• Security best practices

• The XRPL programmability landscape

• Build and deploy Hooks on Xahau and testnet

• Evaluate platforms for specific use cases

• Apply security best practices

• Continue learning as the ecosystem evolves

---

Assignment: Complete a capstone project demonstrating mastery.

Requirements:

Choose ONE:

• Fully functional Hook solving a real problem

• Deployed to Xahau mainnet

• Complete documentation

• Security audit checklist completed

• Original tutorial for Hook developers

• Working code examples

• Covers concepts not in this course

• Published (blog, GitHub, etc.)

• Contribute to an XRPL development tool

• Meaningful PR accepted

• Documentation updated

• Demonstrates understanding

• Project/contribution link

• Brief writeup (500 words) explaining:

Grading:
This is self-assessed. You succeed by completing and learning.

Time investment: 10-20 hours
Value: Portfolio piece and real-world experience

---

Rate yourself 1-5 on each:

1. I can write and deploy a basic Hook: ___
2. I understand guards and why they're necessary: ___
3. I can use state for persistent data: ___
4. I can emit transactions from Hooks: ___
5. I know when to use Hooks vs EVM Sidechain: ___
6. I can identify security vulnerabilities in Hook code: ___
7. I understand the XRPL programmability roadmap: ___
8. I'm confident starting my own Hook project: ___

Scores 4-5: You're ready for production development.
Scores 3: Review specific lessons, practice more.
Scores 1-2: Revisit foundational lessons before proceeding.

---

---

Thank you for completing this comprehensive course on XRPL programmability. The knowledge you've gained positions you at the forefront of blockchain development on one of the most technically sound and institutionally-adopted networks in existence.

The XRPL ecosystem needs skilled developers. Your journey continues from here—go build something meaningful.

---

End of Course

Total words: ~4,200
Total course: ~85,000 words across 20 lessons
Estimated total course time: 50-70 hours