Ok picture this.

You live in a nice, secure house. The locks are good. Best locks as a matter of fact.

Then one day a locksmith knocks on your door and says: "We found a way to pick them last week. You should replace them ASAP."

Yer normal person would respond: "Ok, replace the locks. Let's make it our weekend project."

Blockchain response: "Uhhhh so the locks are actually load-bearing. And also they're welded onto the door. And replacing them requires a governance vote across 10,000 independent node operators, three security audits, a six-month transition period, and we still haven't figured out what to do with the 400 million doors that were already opened using the old lock model. We'll get back to you."

This is the world we live in. And it's about to matter a lot.

+++++++++++++++++++++++

Cryptographic primitives have expiration dates

MD5 was broken in 2004 but it was still in production certificates until 2012. Eight years of running around with passwords that can be decrypted with the right algorithm.

SHA-1 was theoretically dead in 2005. Then practically dead in 2017 when researchers actually demonstrated a collision. It took years of coordination across browsers, certificate authorities, and server operators to fully remove.

RSA-1024 was deprecated by NIST in 2011. But it was still running in enterprise systems a decade later.

This isn't negligence on the part of cryptographers and engineers, but simple migration friction. Knowing your primitive is broken is the easy part. Actually being capable of swapping it out without burning everything down… now that's the hard part. And da danki haz observed that different systems have wildly different abilities to do this.

The technical term for this ability is cryptographic agility. Some systems have a lot of it. And some really good, currently secure systems have very little of it.

The problem is that blockchain and ZK systems are built differently. And when you try to migrate the cryptography in an immutable ledger system, you run into a class of problems that didn't exist before.

TLS has set the bar since 1999

TLS is the protocol behind every HTTPS connection you've ever made. It is ancient by internet standards. It has been upgraded approximately one million times.

The reason it survives repeated upgrades is embarrassingly simple: the algorithm selection happens during the handshake. Before any actual communication, client and server have a little chat: "hey what ciphers do you support?" "oh I support these five, which ones do you have?" "cool, let's use this one."

And believe it or not, that exchange is the whole game. If you need to retire a broken algorithm, you just stop advertising it in the handshake, periodt. If you need to add a new one, you add it to the list. The rest of the protocol doesn't care. It just does whatever the handshake decided.

The algorithm is a mere parameter at the negotiation layer.

TLS 1.3 dropped over 300 weak cipher suite options. Got rid of RC4, 3DES, export ciphers. Hardened the handshake so that an attacker can't force you onto a weaker option — which yes, people tried. POODLE downgraded connections to SSL 3.0. FREAK forced export-grade RSA. LOGJAM targeted weak Diffie-Hellman. 

The whole history of TLS attacks is basically "here's a way to abuse the flexibility we gave you" and TLS's response is always "ok we made the flexibility less flexible in that specific way."

Its high agility made hundreds of migrations painless. It's simple. But by God, it works.

“Hold my beer” - ZK rollups

A ZK rollup works like this: transactions happen offchain, a cryptographic proof is generated proving the transactions were valid, that proof gets submitted to an onchain verifier contract, then the verifier contract checks the proof and finalizes everything.

The security of the whole system rests on that verifier contract. All roads lead to the verifier.

Now the verifier contract is deployed onchain. It implements a specific proof verification system, be it Groth16, PLONK, or STARK, at the bytecode level. It is designed to be immutable, which is good for protocol security, but what if a component of your proving system needs to change?

Well, here's what that will look like:

1. Design and implement the new proof system

2. Get a security audit on the new verifier circuit (several months, $200K–$500K)

3. If you're Groth16-based, you need a new trusted setup ceremony. So, weeks of coordination across multiple independent parties who each generate and then destroy secret randomness (but this probably won’t happen in the next migration, but that’s for another post)

4. Deploy the new verifier contract to L1

5. Run a governance process to update the bridge to recognize the new verifier

6. Migrate all your prover infrastructure to produce proofs under the new system

7. Figure out what to do with every proof ever submitted under the old system, because the new verifier cannot verify them and you kind of need to be able to validate historical state??

8. Pray

No major ZK rollup has completed a full proof system migration in production. As in, it has never happened. We're not talking about something that's been done a few times slowly but something that has never been done once.

The algorithm in this case, lies in the contract, which is in the execution layer. Unfortunately the execution layer was designed to be immutable.

But should you move verifiers outside contracts?

The reason ZK rollups ended up like this is not stupidity. It's tradeoffs.

You want onchain verification because it gives you trustless finality. Any full node can verify the proof independently. Nobody has to trust the rollup operator, and that’s the whole point. Moving verification offchain or behind an abstraction layer reintroduces trust assumptions that ZK rollups were specifically designed to eliminate.

The cost of that decision is that the algorithm is baked in. It seemed worth paying at the time, and honestly, for the goals of the system, it kind of was? They were solving a scalability problem, not planning for a 30-year cryptographic lifecycle.

But when you look closely at why ZK circuits are so hard to migrate, there are actually two different problems bundled together. So don't mix them up or it will lead to bad conclusions.

Problem one: architectural rigidity. This is fixable.

The verifier contract being the migration bottleneck is a design choice. A danki suggestion: build a verifier registry onchain that maps proof system identifiers to verifier contract addresses, and have the bridge call the appropriate verifier per batch. This separates what is being verified from which algorithm does the verifying. You keep trustless onchain verification but add algorithmic flexibility above it.

Now the absence of a specified transition protocol for historical proofs is also just a thing nobody has written down yet. When you migrate from Verifier A to Verifier B, what happens to proofs submitted under A? How long does the old verifier stay callable? What's the sunset timeline? The problem is known in the engineering community. The specification does not exist. But I believe it's fixable.

Problem two: mathematical rigidity. This is not fixable with engineering.

A ZK circuit is a constraint system defined over a specific finite field. The field is not a parameter. It is present in every single constraint in the circuit 🥹A circuit built for the curve BN254 like the ones used in Groth16 and PLONK, does not call BN254. It exists in the algebraic universe defined by BN254's scalar field.

Every field arithmetic operation is an expression in that universe. Every hash gadget is optimized for that field. Every elliptic curve operation is defined by that curve.

If you want to migrate to a different algebraic universe say, one that isn't broken by Shor's algorithm. You're gonna have to rewrite every constraint in the circuit from scratch. The field size determines the size of every arithmetic operation. The hash function determines the structure of every Merkle proof gadget. Dis, you can’t parameterize.

Making ZK circuits algebraically agnostic isn't an engineering sprint. It's an open research problem. The answer to "how do you fix ZK's mathematical rigidity" is not at all "better refactoring", it's "what would a proof system designed for agility even look like." Nobody has built that in production. It's an active research area.

As I’ve said, this distinction matters: if you're a rollup team and you conflate the two, you either get false confidence ("we can just upgrade the contract, it'll be fine") or false despair ("cryptographic migration is impossible for us"). Neither is true. The architectural stuff is fixable now. The mathematical stuff requires a different kind of work.

Actually the scarier problem is your Ethereum address

Your Ethereum address is computed like this:

address = keccak256(pubkey)[12:]

Take not that your address is a hash of your public key. The identity is derived from the cryptographic primitive.

In TLS, your identity lives in a certificate. Your certificate gets reissued when you migrate to a new algorithm but your organizational identity stays the same. The primitive merely attests to the identity but it doesn't constitute the identity.

In Ethereum, the primitive is the identity. If you migrate from ECDSA to a post-quantum signature scheme, you generate a new keypair, which gives you a new address. That new address is a clean slate without your old token balances, history, binded identity, nothing.

For a regular user this is already bad. For a smart contract it's worse: a contract's address is derived from its deployment transaction. You literally cannot change it without redeploying, and redeployment does not inherit state.

And the migration paths that currently exist for Ethereum's quantum vulnerability:

Account abstraction (EIP-7702) lets your account verify post-quantum signatures. Great! But your address is still derived from an ECDSA key. The quantum vulnerability in the identity layer is untouched. I don't have a proposed solution for this yet, but give da danki some time.

New precompiles for ML-DSA / SLH-DSA lets smart contracts call PQC verification natively. Also great! But the address is still ECDSA-derived. So, also unresolved.

Protocol-level hard fork replacing ECDSA is the only option that actually solves it. If addresses derive from PQC keys, the identity coupling problem is gone.

But a caveat: this would be the most expensive migration event in Ethereum's history. Because you’d be coordinating a validator-level hard fork that affects every single Ethereum user. And there is no ratified specification for how the transition would work. If Ethereum picks this path they need to answer questions like: 

• What's the dual-acceptance window? 

• What's the ECDSA sunset timeline? 

• What does account migration look like? 

And if you're choosing this path, the time to specify the transition protocol is now, even though execution is years away. A specification is cheap. A specification during a crisis with a shortened quantum timeline is not. If quantum computers arrive faster than expected and the spec doesn't exist, the coordination problem becomes very difficult under time pressure.

So what do you actually do

If you are building something that needs to survive longer than three years:

Don't put your cryptographic primitive at the execution layer. Put it where negotiation happens. If you're building a ZK protocol, think about the verifier registry early. Way easier to design in than to bolt on after the fact.

Write down your state continuity protocol before you need it. What happens to your historical cryptographic artifacts when you migrate? Where does the old verifier live? What's the sunset? These things are easier to specify in advance but it could f- things up to retrofit during a migration event.

Know what primitives your system depends on and where. In ZK circuits specifically, the dependencies are often invisible at the API level and pervasive at the constraint level. This is the kind of thing you'd want to enumerate before you start planning a migration, not during one. Tooling for this barely exists, so if you're working on ZK you might want to think about it now.

Take harvest-now-decrypt-later seriously. Danki was hacked last week. By a RAT. And… nothing happened. Which made me think about schemes like this. Have they copied my hot wallet vault? Well it doesn't matter coz I'm comparatively too broke for this effort. But for escrows, governance, vesting contracts… it will be very worth it. 

Know whether your problem is architectural or mathematical. Because the response to each is completely different. One is a sprint. One is a research program.

+++++++++++++++++++++++

The thing that keeps me up about this — and I promise I have other things that keep me up, I'm not that far gone — is that the infrastructure we've been building for the last five years was optimized for the right things. Correctness. Performance. Trustlessness. Those are genuinely the right things to optimize for.

But there’s tradeoff between "the system is maximally correct right now" and "the system can survive being wrong about what correct means in ten years." And that tradeoff was often not made explicitly. It was made by default, so maybe it’s time to be explicit about this.

After all, you don't find out how agile your system is when everything works. You find out the moment you have to change it.

At that point, we have something that works. But working is not the same as surviving.

So in this part, I'm gonna talk about what's missing what else you need to actually tokenize a local asset.

Security Fixes You Need to Know About

While building this, I found (and fixed) several critical issues that would have ruined your day in production:

1. Bank Run Prevention

finalizeRedemption() could credit withdrawals without checking if the contract has sufficient USDC.

The attack:

1. Oracle finalizes 100 redemptions for $1M total

2. Contract only has $100k USDC

3. First 10 users withdraw successfully

4. Next 90 users get transfer failed

5. Their tokens are already burned

6. They're rugged

fix:

// CRITICAL: Verify contract has sufficient USDC before crediting
uint256 contractBalance = i_usdc.balanceOf(address(this));
require(contractBalance >= usdcAmount, "insufficient contract balance");

2. Double-Redemption Prevention

The attack:

1. User requests redemption (tokens burned)

2. Oracle is slow, 8 days pass

3. User cancels, gets tokens back

4. Oracle finalizes redemption (still works!)

5. User withdraws USDC

6. User has BOTH tokens AND USDC

7. Protocol is drained

fix:

// Check request hasn't expired (prevent double-redemption via cancel)
if (isRequestExpired(requestId)) {
    revert RedemptionManager__RequestExpired();
}

3. Decimal Precision

I call this the slow rug. But not really, it's just taking invisible conversion fees from your users.

The theft:

1. Say, user has 1.999999999999999999 USDC (18 decimals) = $2

2. Converts to 1.999999 USDC (6 decimals) = $1.999999

3. Lost: $0.000001

4. Over 1M redemptions: $1,000 stolen from users

fix:

// Round up instead of truncate to favor users (never underpay)
return (amount + 1e12 - 1) / 1e12;

Protocol absorbs the negligible rounding cost (<$0.000001 per withdrawal) instead of users. This is okay. I did a little research on this and figured this also is how traditional accounting systems work.

There are many more, but these are the common mistakes that might get missed by yer static analyzers.

What This Code Is Missing

While we may have done tackled the whole RWA architecture by now, there are still plenty of considerations that you need to take in mind before you run this in prod.

1. Multisig Governance

This thing still runs on a single admin/agent keys. Get at least a 3-of-5 Gnosis Safe for all privileged operations.

2. Circuit Breakers

Having circuit breakers require you to have a monitoring infrastructure and complex state management, but you need it. There must be a way to auto-pause the market on anomalies eg. >10% price moves, high redemption volume, etc.

3. Real KYC/AML Integration

I have oversimplified the AMLA module on Part 1 to make it easily digestible. In reality, you need real-time sanctions screening, claim verification, chain analytics... and these require you to have licensed provider APIs and ongoing compliance.

4. Custody Integration for Proof of Reserves

This actually requires legal agreements and enterprise accounts. We only have mock oracles in this tutorial.

5. Brokerage API Integration

We have used manual oracles for simplicity, but it will be comedy if you try this in real life environments. Your brokerage first needs to have an API, and it must be accessible to you and support your stack.

If you want to launch this in production, you need:

• 12-15 months of development, with prerequisites

• 5-10 person team (engineers, compliance, operations)

• A huge budget (modernity is expensive)

How to: Philippine RWA Tokenization

If you're looking to implement this with Philippine-based assets (PSE stocks, Pagibig bonds, real estate tokens), the regulatory landscape is still on its way. But structurally, here's what you need on the tech side:

1. Brokerage API: for securities like in our tutorial, API from PSE-compatible brokers (COL Financial, BPI Trade, etc.), connect to the oracles.

2. KYC Provider: I highly recommend we have a self-custodial DID system that is gated by National ID. This is another long topic! But if not, a traditional KYC system will work. Connect it to the IdentityRegistry contract.

3. Custody: Local qualified custodian

4. Regulatory registration and all legal matters (Sorry, can't help you on this one)

But architecture-wise and code-wise, things remain. Swap the API endpoints, update the KYC provider, get local legal counsel. The smart contracts don't care if you're tokenizing AAPL or Jollibee stock. 🍗

The Part Where I Tell You Not To Use This

This code is excellent for learning.
It shows you how identity plugs into tokens, why compliance can’t be an afterthought, how redemption actually works, and where oracles fit into the system.

But this code is NOT ready for production. It’s missing the parts that actually make a system survive.

So, what you can do now:

1. Clone the repo and run the tests

2. Modify the contracts for your use case

3. Experiment with different compliance modules

4. Understand the architecture before adding infrastructure

What you should NOT do with this tutorial:

• Launch with real assets (seriously, don't)

• Handle real user funds (I will find you)

• Claim production-readiness (you will get sued)

• Deploy to mainnet without modifications (you will get rekt)

If you're building a production RWA protocol and need help with architecture, security, compliance, or just plain need advice, reach out. I've been studying its patterns for a while, and I know where the bodies are buried.

Resources:

Danki's Full Tutorial code: Github Repo

ERC-3643 Standard: Docs

Chainlink Oracle: Docs

Patrick Collin's RWA Tutorial (Special thanks): Github Repo

We didn’t start with minting until we have an identity registry. We separated compliance from token logic. We made sure the transfers weren’t just balance checks, but decisions based on who is allowed to participate. At that point, your token stopped being a toy.

But everything we’ve built so far is still perfectly self-contained. Smart contracts can't make HTTP requests. They can't check your brokerage account. They can't know if you, as the RWA token issuer actually own the assets.

So now we introduce the part everyone loves to oversimplify: oracles.

Step 3 — Oracle Layer (Reality Exists Outside)

Not all oracles are equal. And more importantly, you will almost always need more than one. Because you’re not just asking one question. You’re asking many:

• what is the current price of this asset?

• is this token actually backed?

• did something happen offchain that should update state onchain?

• has a redemption request been fulfilled?

Each of these will need information from offchain. Let's put our price oracle and proof of reserve oracle now:

// src/oracle/interfaces/IPriceOracle.sol
interface IPriceOracle {
    function latestRoundData() external view returns (
        uint80 roundId,
        int256 answer,      // Price with 8 decimals
        uint256 startedAt,
        uint256 updatedAt,
        uint80 answeredInRound
    );
}


// src/oracle/interfaces/IAttestationOracle.sol
interface IAttestationOracle {
    function hasReserves(string memory asset, uint256 amount)
        external view returns (bool);
}

As an example, I'm using Chainlink for both price feed and Proof of Reserve attestation

Again, separation of concerns: Oracles should be mere data providers, if you must enforce logic for transfers and other things, do them on a separate contract.

Moving on...

Your data should also have an expiration date. If the oracle hasn't updated in 3 hours, the price might be wrong. Using stale data can lead to:

• Minting tokens at wrong price (loss for protocol)

• Redemptions at wrong price (loss for users)

• Arbitrage (loss for everyone T_T)

So, it's better to revert than use stale data.

Let's create a utility to do the staleness check on our price feed:

// src/oracle/libraries/OracleLib.sol
library OracleLib {
    uint256 private constant TIMEOUT = 3 hours;
   
    function staleCheckLatestRoundData(IPriceOracle priceFeed)
        internal view returns (uint80, int256, uint256, uint256, uint80)
    {
        (uint80 roundId, int256 answer, uint256 startedAt, uint256 updatedAt, uint80 answeredInRound) =
            priceFeed.latestRoundData();
       
        // Check for stale price
        uint256 secondsSince = block.timestamp - updatedAt;
        if (secondsSince > TIMEOUT) {
            revert OracleLib__StalePrice();
        }
       
        // Check for invalid price
        if (answer <= 0) {
            revert OracleLib__InvalidPrice();
        }
       
        return (roundId, answer, startedAt, updatedAt, answeredInRound);
    }
}

Great! Now there are still other things you need an oracle for. For example, making sure that the system knows whether a token redemption request has been fullfilled in the physical world.

You can find the sample code for other oracles in my repo.

Step 4 — Stock Token (The Orchestrator)

Finally, this is where we bring it all together. We'll use a token with ERC20 mechanics to represent our stock, but with additional rules:

// src/token/StockToken.sol
contract StockToken is ERC20, AccessControl {
    IIdentityRegistry private _identityRegistry;
    IModularCompliance private _compliance;
    IAttestationOracle private _attestationOracle;
    bool private _requireAttestation;
   
    function transfer(address to, uint256 amount)
        public override whenNotPaused returns (bool)
    {
        address from = msg.sender;
       
        // 1. Check freezing
        require(!_frozen[from] && !_frozen[to], "address frozen");
       
        // 2. Check unfrozen balance
        require(balanceOf(from) - _frozenTokens[from] >= amount, "insufficient unfrozen balance");
       
        // 3. Check identity verification
        require(_identityRegistry.isVerified(to), "receiver not verified");
       
        // 4. Check compliance
        require(_compliance.canTransfer(from, to, amount), "not compliant");
       
        // 5. Execute transfer
        _transfer(from, to, amount);
       
        // 6. Notify compliance (for state updates)
        _compliance.transferred(from, to, amount);
       
        return true;
    }
   
    function mint(address to, uint256 amount) public onlyAgent {
        require(_identityRegistry.isVerified(to), "receiver not verified");
        require(_compliance.canTransfer(address(0), to, amount), "mint not compliant");
       
        // Optional: Verify backing via attestation oracle
        if (_requireAttestation && address(_attestationOracle) != address(0)) {
            require(
                _attestationOracle.hasReserves("STOCK", amount),
                "insufficient reserves"
            );
        }
       
        _mint(to, amount);
        _compliance.created(to, amount);
    }
}

Now you can see that our StockToken does a couple of things that are not normally part of an ERC20 behavior:

• it delegates verification to IdentityRegistry

• it delegates rules to Compliance

• integrates data from offchain through oracles (disabled by default for this tutorial)

Notice that transfer cannot happen if the address of msg.sender or to is not part of the verified and compliant list.

If you want to check, clone our repo and run forge test --match-contract StockTokenTest to verify transfers are restricted.

What if the regulators required wallet freezing?

In some scenarios, you might be required to add a freezing and force transfer function in case of things like court orders, violations, or suspicious activities... Here's how you do it:

mapping(address => bool) private _frozen;
mapping(address => uint256) private _frozenTokens;


function setAddressFrozen(address wallet, bool freeze) public onlyAgent {
    _frozen[wallet] = freeze;
    emit AddressFrozen(wallet, freeze, msg.sender);
}


function freezePartialTokens(address wallet, uint256 amount) external onlyAgent {
    _frozenTokens[wallet] += amount;
    emit TokensFrozen(wallet, amount);
}

function forcedTransfer(address from, address to, uint256 amount)
    public onlyAgent returns (bool)
{
    require(balanceOf(from) >= amount, "insufficient balance");
    require(_identityRegistry.isVerified(to), "receiver not verified");
   
    // Unfreeze tokens if needed
    uint256 freeBalance = balanceOf(from) - _frozenTokens[from];
    if (amount > freeBalance) {
        uint256 tokensToUnfreeze = amount - freeBalance;
        _frozenTokens[from] -= tokensToUnfreeze;
    }
   
    // Execute transfer (bypass compliance for forced transfers)
    _transfer(from, to, amount);
    _compliance.transferred(from, to, amount);
   
    return true;
}

In danki code, forced transfers bypass compliance checks but still verify receiver identity. This is intentional, court orders don't care about daily transfer limits.

Yaiy, great. We're down to the final and most important piece:

Step 5 — Redemption Flow

There's one little problem when redeeming a stock token: blockchains are synchronous. Stock markets are asynchronous. You can't sell a stock in the same transaction you burn the token.

In the blockchain:

• everything inside a transaction happens immediately and atomically

• either the whole thing succeeds, or it fails

• there is no waiting, no callbacks, no “come back later”

But you can't do that in real markets. In real stock trading, everything is delayed, queued, and processed externally:

1. you request to sell TSLA

2. broker submits order

3. exchange matches it

4. settlement happens (T+2, sometimes faster but still not instant)

5. cash is credited

This can take seconds to execute and sometimes days to settle.

Solving this separates real RWA from a cosplaying ERC20. And I'll tell you how.

We create a 3-step async redemption process. The solution is a bit long this time, and please take note that THIS IS NOT MY PRODUCTION CODE, but here we go:

// src/redemption/RedemptionManager.sol
contract RedemptionManager is AccessControl, ReentrancyGuard {
    bytes32 public constant ORACLE_ROLE = keccak256("ORACLE_ROLE");
   
    struct RedemptionRequest {
        address user;
        uint256 tokenAmount;
        uint256 expectedUsdc;
        uint256 timestamp;
        bool fulfilled;
    }
   
    mapping(bytes32 => RedemptionRequest) private s_redemptionRequests;
    mapping(address => uint256) private s_withdrawalBalance;
    mapping(address => bytes32[]) private s_userRequests; // Track user's requests
   
    // Step 1: User requests redemption
    function requestRedemption(uint256 tokenAmount)
        external nonReentrant returns (bytes32 requestId)
    {
        // Calculate expected USDC
        uint256 stockPrice = i_stockPriceOracle.getPrice();
        uint256 usdcPrice = i_usdcPriceOracle.getPrice();
        uint256 expectedUsdc = (tokenAmount * stockPrice) / usdcPrice;
       
        // Generate unique request ID
        requestId = keccak256(abi.encodePacked(
            msg.sender,
            tokenAmount,
            block.timestamp,
            s_requestCounter++
        ));
       
        // Store request
        s_redemptionRequests[requestId] = RedemptionRequest({
            user: msg.sender,
            tokenAmount: tokenAmount,
            expectedUsdc: expectedUsdc,
            timestamp: block.timestamp,
            fulfilled: false
        });
       
        // Track for user
        s_userRequests[msg.sender].push(requestId);
       
        // Burn tokens immediately (prevents double-spending)
        i_stockToken.burn(msg.sender, tokenAmount);
       
        emit RedemptionRequested(requestId, msg.sender, tokenAmount, expectedUsdc);
    }
   
    // Step 2: Oracle finalizes after selling stock off-chain
    function finalizeRedemption(bytes32 requestId, uint256 usdcAmount)
        external onlyRole(ORACLE_ROLE) nonReentrant
    {
        RedemptionRequest storage request = s_redemptionRequests[requestId];
       
        require(request.user != address(0), "request not found");
        require(!request.fulfilled, "already fulfilled");
        require(!isRequestExpired(requestId), "request expired");
       
        // Check slippage (allow up to 2% deviation)
        uint256 minAcceptable = (request.expectedUsdc * 98) / 100;
        require(usdcAmount >= minAcceptable, "slippage exceeded");
       
        // CRITICAL: Verify contract has sufficient USDC
        uint256 contractBalance = i_usdc.balanceOf(address(this));
        require(contractBalance >= usdcAmount, "insufficient contract balance");
       
        // Mark as fulfilled
        request.fulfilled = true;
       
        // Credit user's withdrawal balance
        s_withdrawalBalance[request.user] += usdcAmount;
       
        emit RedemptionFulfilled(requestId, request.user, usdcAmount);
    }
   
    // Step 3: User withdraws USDC
    function withdraw() external nonReentrant returns (uint256 amount) {
        amount = s_withdrawalBalance[msg.sender];
        require(amount > 0, "no balance");
       
        // Clear balance before transfer (CEI pattern)
        s_withdrawalBalance[msg.sender] = 0;
       
        // Transfer USDC (with rounding up to favor user)
        uint256 usdcAmount = (amount + 1e12 - 1) / 1e12; // 18 decimals → 6 decimals
        require(i_usdc.transfer(msg.sender, usdcAmount), "transfer failed");
       
        emit Withdrawn(msg.sender, amount);
    }
   
    // Helper: Get user's pending requests
    function getPendingRequests(address user)
        external view returns (bytes32[] memory)
    {
        bytes32[] memory allRequests = s_userRequests[user];
        uint256 pendingCount = 0;
       
        // Count pending
        for (uint256 i = 0; i < allRequests.length; i++) {
            if (!s_redemptionRequests[allRequests[i]].fulfilled) {
                pendingCount++;
            }
        }
       
        // Build array
        bytes32[] memory pending = new bytes32[](pendingCount);
        uint256 index = 0;
        for (uint256 i = 0; i < allRequests.length; i++) {
            if (!s_redemptionRequests[allRequests[i]].fulfilled) {
                pending[index++] = allRequests[i];
            }
        }
       
        return pending;
    }
}

Redemption here happens in 3 steps:

1. The user requests redemption. We estimate the USDC using oracle prices, store the request, and burn the tokens immediately. Burn first, ask questions later. No double-spending or pretending you still hold the asset.

2. The oracle finalizes after the stock is actually sold offchain. This is the part people like to handwave. The chain can’t wait for brokers or settlement, so we don’t fake it. Offchain happens first, then the oracle comes back and settles it onchain. We check slippage and make sure the money is actually there.

3. The user withdraws. For security reasons, we don’t push funds automatically... we credit a balance and let them pull. Great, fewer ways to get rekt.

That’s async redemption for you. You can burn a token instantly but you cannot sell a stock instantly.

A few more notes on this design: oracle pays for finalization and user pays for withdrawal, plus this accumulate multiple redemptions in batches for gas efficiency. Also, if user loses their requestId, they can't cancel expired requests. This design track all requests per user so they can always query their pending redemptions.

Step 6 — Offchain Integrations

Unfortunately with RWA, the backend is part of your system.

Smart contracts are great at enforcing rules. They're terrible at making HTTP requests, communicating with brokerage accounts, or knowing if you actually sold the stock.

So you need an off-chain service that listens for on-chain events, executes real-world actions (sell stock, buy USDC), and reports them back to the chain.

This is not optional. This is the entire point of RWA.

The only catch is that your backend is now a trusted party. Which means if it lies, breaks, or gets owned, your redemption flow goes with it. Audit accordingly.

Let's make an event listener:

// Backend service listening for redemption events
contract.on("RedemptionRequested", async (requestId, user, tokenAmount, expectedUsdc) => {
    console.log(`Redemption requested: ${requestId}`);
   
    // 1. Sell stock on brokerage (Alpaca, Interactive Brokers, etc.)
    const order = await brokerage.sellStock("AAPL", tokenAmount);
    await order.waitForExecution(); // Wait for T+2 settlement
   
    // 2. Receive USD proceeds
    const proceeds = order.filledValue;
    console.log(`Sold for $${proceeds}`);
   
    // 3. Convert to USDC (via DEX or OTC)
    const usdc = await convertToUsdc(proceeds);
   
    // 4. Send USDC to RedemptionManager
    await usdcContract.transfer(redemptionManager.address, usdc);
   
    // 5. Finalize redemption on-chain
    await redemptionManager.finalizeRedemption(requestId, usdc);
   
    console.log(`Redemption finalized: ${requestId}`);
});

Again, not production code. In real life, you will integrate this using a real oracle, Ethers and Alpaca. But this should give you a good overview of how it looks like.

This is where the "RWA" part happens. The smart contract is just the on-chain interface. The real work (selling stocks, converting to USDC) happens off-chain. It's unavoidable. And this is why RWA is hard. Not because of Solidity. Because of integrating blockchain with traditional finance.

At this point, we’ve crossed the boundary.

Our self-contained smart contract system in Part 1 is now something else entirely.

We’ve:

• introduced external data through oracles

• modeled asynchronous redemption instead of pretending everything settles instantly

• and came to acceptance that offchain systems are part of the architecture

In Part 3, we’ll go through everything this code is still missing if you want to use it in production.

We’ll cover:

• common RWA security vulnerabilities and quick prevention advice

• what you actually need before calling this “production-ready”

• and the migration path to implementing this with Philippine assets

Because honestly you can make these contracts compile in an afternoon. But you'll spend the rest of your time making sure it doesn’t break in the real world.

See you on the final round! 🐴

Everyone suddenly wants to “tokenize assets” like it’s just another token deployment with more serious looking names attached to them.

It's not. An RWA system is:

• permissioned

• identity-aware

• compliance-heavy

• and very, very allergic to “just ship it” instincts that we've grown accustomed to

So let's try it. Let's build a demo tokenized stock using ERC-3643 — with identity, compliance, oracle-fed data, and a redemption path.

What you'll learn:

• How to restrict token transfers to verified investors only

• Why compliance needs to be modular (spoiler: regulations change)

• Why redemption can't be instant (spoiler: blockchains are synchronous, stock markets aren't)

• Where oracles fit (and where they don't)

What you won't learn:

• How to avoid securities regulations (you can't)

• How to launch this in production (you shouldn't, without serious infrastructure and security processes)

• How to get rich quick (wrong tutorial)

Let's go mah frens 🐴

FULL REPOSITORY HERE

---

Why You're Getting Mocks...

Full disclosure: I built a fully functional version of this using Alpaca API for permissionless stock trading. It works elegantly. And I'm never shipping it publicly.

Why?

First of all, offering securities without proper licensing is a regulatory nightmare

"But it's decentralized!" is not a legal defense (ask the Luna folks), and Danki prefers devrelling over eating prison food.

Nevertheless, I still teach you the exact same architecture with mock infrastructure. You'll understand how ERC-3643 is implemented. We'll use commonly used compliance patterns. With real async redemption flow (because T+2 settlement is reality). We'll even use real oracle integration patterns.

The only difference is we'll have mock oracles instead of live API calls. When you're ready to go live (with proper licensing), you swap 50 lines of mock code for real API calls.

Oh, and a bonus: I'll show you how this applies to Philippine-based assets (PSE stocks, real estate tokens) where the regulatory path is clearer.

Synthetic vs Backed RWAs (Stop Confusing Them)

Before we build anything, let’s clean this up.

A synthetic RWA gives you exposure. A backed RWA gives you a claim.

If you back an RWA with something that lives onchain (eg. wBTC, ETH, USDC, LUNA), it's a synthetically backed asset. In synthetically backed RWA, you can't actually claim the asset, but you can claim the tokens backing the value that it represents.

If you're RWA is backed by the exact asset that it represents, then it's an asset-backed RWA. This type is enforceable, and should be redeemable. The downside is that it is reliant on oracles that brings your offchain data onchain.

For this tutorial, we’re modeling a backed RWA architecture.

That means:

• the token represents a claim

• the holder must be eligible

• transfers are restricted

• redemption exists

If any of those are missing… you already know 🐴

Components of an RWA System

Before we touch code, we need to understand the moving parts.

┌─────────────────────────────────────────────────────────────┐
│  															                      StockToken                        											    │
│  											Main ERC20 token with identity and compliance integration 								│
└────────────┬────────────────────────────────────────────────┘
     						         │
		    ┌────────┴────────┬──────────────┬─────────────┐
		    │            									   │            						   	 │            						 │
  		    ▼             							       ▼           							▼          						    ▼
┌─────────┐   ┌──────────────┐  ┌─────────┐  ┌──────────────┐
│		Identity 		│   │ 			Compliance 	     │  │ 		Oracles	  │  │			 Redemption	     │
│		Registry		│   │			 (Modular)    	   	│  │        				 │  │ 			Manager  	         │
└─────────┘   └──────────────┘  └─────────┘  └──────────────┘

1. Contracts (The Stack, Not Just the Token)

ERC-3643 is a suite, not a single contract.

At minimum, you’re working with:

• Token (StockToken) → the actual asset representation

• Identity Registry → who is allowed to hold

• Claim Topics Registry → what requirements exist (KYC, accreditation, etc.)

• Trusted Issuers Registry → who is allowed to verify users

• Compliance Contract → decides if transfers are allowed

Optional:

• Oracle contracts → price, reserves, events

• Redemption manager → where offchain meets reality

If your system is just:

mint( );
transfer( );

😭 please close your laptop.

2. Compliance Frameworks (Yes, You Need This)

In ERC-3643 compliance means:

• wallets are mapped to identities who can carry claims

• claims come from trusted issuers

• compliance checks happen on every transfer

Which means:

your token doesn’t just care about balances
it cares about who is moving them

3. Oracles (Plural, Not One Magic Pipe)

You don’t have “an oracle.” You have multiple.

For a tokenized stock, you might need:

• price oracle → “what is this stock worth?”

• reserve / attestation oracle → “is this actually backed?”

• compliance oracle → offchain KYC systems

• corporate actions oracle → dividends, splits, etc.

• settlement signal → redemption completed

Ok, enough talking.

Now, install your Foundry and Openzeppellin. They're our dependencies.

Step 0 — Set Up Your Repo

This will be our file structure:

/contracts
  /identity
  /compliance
  /oracle
  /redemption
  /token

/test
 	/integration 
	/unit

Step 1 — Identity First (Not Token First)

Map wallets to identity:

// src/identity/IdentityRegistry.sol
contract IdentityRegistry is AccessControl {
    bytes32 public constant AGENT_ROLE = keccak256("AGENT_ROLE");
   
    // Wallet → Identity contract mapping
    mapping(address => IIdentity) private _identities;
    mapping(address => uint16) private _investorCountry;
   
    function registerIdentity(
        address wallet,
        IIdentity identityContract,
        uint16 country
    ) external onlyRole(AGENT_ROLE) {
        require(wallet != address(0), "invalid wallet");
        require(address(identityContract) != address(0), "invalid identity");
        require(address(_identities[wallet]) == address(0), "already registered");
       
        _identities[wallet] = identityContract;
        _investorCountry[wallet] = country;
       
        emit IdentityRegistered(wallet, identityContract);
    }
   
    function isVerified(address wallet) external view returns (bool) {
        return address(_identities[wallet]) != address(0);
    }
   
    function deleteIdentity(address wallet) external onlyRole(AGENT_ROLE) {
        IIdentity oldIdentity = _identities[wallet];
        require(address(oldIdentity) != address(0), "not registered");
       
        delete _identities[wallet];
        delete _investorCountry[wallet];
       
        emit IdentityRemoved(wallet, oldIdentity);
    }
}

No identity = no participation

Some decisions I made:

1. Instead of storing KYC data on-chain (expensive, privacy nightmare), we store a reference to an identity contract. The identity contract holds claims issued by KYC providers.

2. Only authorized KYC providers can register identities. This isn't permissionless DeFi anymore.

3. I did a mock country tracking. Different countries have different rules. We need to know where investors are located.

What this does NOT do:

• Store KYC data

• Enforce transfer limits

• Check prices

We're all doing these somewhere else, because separation of concerns matters. I let each contract do one thing well.

Important note on identity:

The full ERC-3643 standard uses claims for verification:

interface IIdentity {
    function getClaim(bytes32 claimId) external view returns (
        uint256 topic,      // What type of claim (KYC, accreditation, etc.)
        uint256 scheme,     // Signature scheme
        address issuer,     // Who issued the claim
        bytes signature,    // Cryptographic proof
        bytes data,         // Claim data
        string uri          // Additional info
    );
}

And how it works in practice is:

1. User completes KYC with provider

2. Provider issues a claim (cryptographically signed)

3. Claim is stored in user's ONCHAINID contract

Token contract verifies claim before allowing transfers. Please don't skip this if you're using on prod. It's very important for future features because:

• KYC provider can revoke claims in case user gets sactioned

• Multiple providers can issue claims (no central provider)

• We have privacy-preserving considerations (claim data can be hashed)

  For this tutorial, we use simplified verification (just check if identity exists). Full claim verification can be added later without changing the architecture.

Step 3 — Compliance Layer

Different jurisdictions have different rules. Rules change over time. You can't hardcode compliance logic. So we'll have pluggable compliance modules

// src/compliance/ModularCompliance.sol
contract ModularCompliance is Ownable {
    IModule[] private _modules;
   
    function canTransfer(address from, address to, uint256 amount)
        external view returns (bool)
    {
        // Check ALL modules
        for (uint256 i = 0; i < _modules.length; i++) {
            if (!_modules[i].moduleCheck(from, to, amount, address(this))) {
                return false; // ANY module can reject
            }
        }
        return true; // ALL modules must approve
    }
   
    function transferred(address from, address to, uint256 amount)
        external onlyToken
    {
        // Notify ALL modules (for state updates)
        for (uint256 i = 0; i < _modules.length; i++) {
            _modules[i].moduleTransferAction(from, to, amount);
        }
    }
}

Notice we have two functions:

canTransfer() (view function): Pre-transfer validation. Returns true/false. No state changes.

transferred() (state-changing): Post-transfer state update. Modules update their internal state.

Why this pattern?

Because view functions can't change state. If modules need to track balances or daily limits, they need a separate function called AFTER the transfer succeeds.

This is the part that trips people up. Let me show you why it matters.

Here's an example module I created, Max Balance Limit (yor regular AMLA module):

// src/compliance/modules/MaxBalanceModule.sol
contract MaxBalanceModule is AbstractModule {
    uint256 public maxBalance;
   
    // Track balance per IDENTITY (not per wallet)
    mapping(address => uint256) public identityBalance;
   
    function moduleCheck(address /* from */, address to, uint256 amount, address /* compliance */)
        external view returns (bool)
    {
        address toIdentity = _getIdentity(to);
       
        // Check if receiver would exceed max balance
        if (identityBalance[toIdentity] + amount > maxBalance) {
            return false;
        }
       
        return true;
    }
   
    function moduleTransferAction(address from, address to, uint256 amount)
        external onlyBoundCompliance
    {
        address fromIdentity = _getIdentity(from);
        address toIdentity = _getIdentity(to);
       
        // Update balances
        if (from != address(0) && fromIdentity != address(0)) {
            identityBalance[fromIdentity] -= amount;
        }
       
        if (toIdentity != address(0)) {
            identityBalance[toIdentity] += amount;
        }
    }
}

Why track by identity, not wallet?

Because one person can have multiple wallets. If we track by wallet, they can bypass limits by using 10 different addresses.

And one more, here's a critical pitfall that will break your system:

Don't check sender balance in moduleCheck(). The module's internal balance is only updated AFTER the transfer. Checking sender balance in moduleCheck() creates a deadlock where transfers always fail.

// WRONG: This will always fail
function moduleCheck(address from, address to, uint256 amount) {
    address fromIdentity = _getIdentity(from);
   
    // This checks module's internal balance, which hasn't been updated yet!
    if (identityBalance[fromIdentity] < amount) {
        return false; // DEADLOCK MAH FREN
    }
   
    // ...
}

here's how to do it correctly:

// Token contract checks sender balance, module checks receiver limit
function moduleCheck(address /* from */, address to, uint256 amount) {
    address toIdentity = _getIdentity(to);
   
    // Only check receiver's limit
    if (identityBalance[toIdentity] + amount > maxBalance) {
        return false;
    }
   
    return true;
}

So you see, between the token and the modules, there is separation of functions:
Your Token contract: Validates sender has sufficient balance (ERC20 standard)

Your Compliance module: Validates business rules (receiver limits, daily caps, etc.)

Mix them up if you're having fun on test environments. But so far, this is what works.

Let's try another AMLA module 🐴

// src/compliance/modules/TransferLimitModule.sol
contract TransferLimitModule is AbstractModule {
    uint256 public dailyLimit;
   
    // identity => day => volume
    mapping(address => mapping(uint256 => uint256)) public dailyTransferVolume;
   
    function moduleCheck(address from, address /* to */, uint256 amount, address /* compliance */)
        external view returns (bool)
    {
        address fromIdentity = _getIdentity(from);
        uint256 today = block.timestamp / 1 days;
       
        uint256 currentVolume = dailyTransferVolume[fromIdentity][today];
       
        if (currentVolume + amount > dailyLimit) {
            return false;
        }
       
        return true;
    }
   
    function moduleTransferAction(address from, address /* to */, uint256 amount)
        external onlyBoundCompliance
    {
        address fromIdentity = _getIdentity(from);
        uint256 today = block.timestamp / 1 days;
       
        dailyTransferVolume[fromIdentity][today] += amount;
    }
}

Why daily limits?

• Prevents rapid liquidation (market manipulation)

• Complies with Reg D restrictions (limited resale)

• Detects suspicious activity (sudden large transfers = 🚨)

Auto-reset: Counters automatically reset when today changes (new day = new timestamp / 1 days).

Great, we've now set up an identity and compliance system.

We now have:

• a system that knows who is allowed to participate

• a compliance layer that enforces rules at transfer time

• and a clear separation between identity, policy, and token behavior

In Part 2, we’ll wire this system into the outside world:

• bring in oracle data

• implement token behavior that reflects regulatory constraints

• and design a redemption flow that doesn’t pretend blockchains can settle instantly

That's all for now. Danki will be egg hunting. I'll be back on Easter! 🐴🐤🐰🥚

An ERC20 token is self-contained. Its value, behavior, and rules live entirely onchain.

RWAs don’t work like that. RWAs are actual legal claims represented by a token. It’s something that even I am still finding difficult to grasp as a cryptonative.

Because if it’s a legal claim, it means my system is no longer just smart contracts and math. It’s:

• smart contracts + regulation and documents

• da government

• data pipelines

• and physical and legal constraints i can’t just require() away

Which makes me wonder how come all these cryptonative people seem to know and promote RWA when I’m still grappling with the idea that not all asset ownership can be fully decentralized. 

It turns out, it’s because a lot of people aren’t actually thinking about RWAs in their full complexity.

They’re thinking about it like fractional NFTs… where you take an asset, split it into tokens, and assume ownership just magically works because it’s onchain.

The Fractional NFT Brain

A lot of the hot air around RWAs goes like this: “we tokenize the asset and split it into shares”

That works for NFTs where the asset is the token. But if you’re planning to have that token to represent an asset that lives in the physical space, that gets a little more complex, innit?

My chad,

• the asset you’re trying to trade onchain, exists outside the chain

• tokens merely represent and it can depeg if you didn’t do it right

• ownership depends on whether someone offchain actually honors it

So… the question should not be “how do i represent this asset”? That is the easy part. The question is,  “What happens when I redeem this token?” and the answer should never be “There’s no path to convert it to its tangible version”

A tokenized RWA should always (and at all times) map the token to a real, enforceable claim. And we’re not done yet, there should always be a path to execute that obligation. Otherwise… you didn’t build an RWA. You built a token with really convincing, but false marketing.

Ok, let’s go back to dankying with code. 

This is Why ERC-3643 Exists

This is where standards like ERC-3643 come in.

First of all, it’s not another NFT standard. You can actually use it alongside other core token standards.

It’s basically a way to introduce constraints that regular tokens don’t have. 3643 is useful when:

1. you can’t let just anyone hold the token

2. you need customized control over its circulation

3. you need identity, compliance, and restrictions baked into their transfers

And to hold those conditions true, you need an identity registry for that.

So your token now needs to care who you are and to whom you are transferring it to. Which  sounds so not cypherpunk… but who says cypherpunk technologies are only for us weirdos at the edges. They can do wonders in making traditional systems more efficient and secure too.

That doesn’t contradict the self-sovereign internet we’re building toward. If anything, this is how we get there.

Some things are fundamentally off-chain…

Blockchains are deterministic. It’s incredibly good at verifying and enforcing rules on things that live inside them. Deploy a contract and the chain enforces it predictably, and everyone agrees on account balances, signatures, and state transitions. 

But what happens if your application needs info that doesn’t live inside the chain?

Your contract cannot tell if that building actually exists. It cannot confirm whether gold is sitting in a vault somewhere. It has no idea if a security is legally enforceable or if the issuer just decided to disappear one day. And to make things more complicated, it cannot limit the trading of these assets to only eligible entities if their identities are not verifiable onchain.

So RWAs end up depending on things that feel… uncomfortable for cryptonatives like Danki.

Because that means we’re going to rely on custodians to hold assets, oracles to report state, attestations to bridge user information, and legal agreements to actually enforce ownership. Suddenly, you’re not designing a trustless system anymore.

You’re designing a system that has a lot of trust assumptions. This is where I personally think regulators need to enter, not as a complication in the story, but as part of the design.

Regulation Is Not Optional

If you’re building RWAs seriously, you will run into:

• KYC / AML requirements

• jurisdiction restrictions

• transfer limitations

• licensing questions

And as an engineer, you will need help too. Let’s say Danki haz built the cleanest, most beautiful RWA smart contract ever. But my proof of reserve connects to a spreadsheet that manually updates every week 🥹

Or my oracle is an API that I just vibecoded with Claude

Or my token transfer requirements verify somebody’s eligibility through a digital pinkyswear.

My point being… the system is only as strong as its weakest offchain assumption. 

There are problems you cannot solve as a dev. It’s sometimes wise to work with institutions to minimize these risks. 

There’s also this instinct a lot of devs have: “we’ll deal with offchain integrations later.”

No, you won’t 🐴

Because by the time you’re thinking about integrations, you’ve already made design decisions that either support it or break it entirely. Who can hold the token, who can transfer it, where it’s allowed to move, how redemption works... These aren’t things you can easily undo for a token.

You don’t bolt compliance on top of an RWA system. By the time you deploy, whether it’s a purely onchain thing or not is already embedded into its logic. And pretending regulation doesn’t exist for your underlying asset doesn’t make your system more aligned with crypto ideals. It just means you’re launching a fractional memecoin, for the time being 😏

Then Why Do We Even Bother?

This is a personal opinion.

If we want our onchain systems to mature, I’m all for testing out where it can help with coordination, verifiability, and transparency. Not just inside our own ecosystems, but in places where things already matter.

I will support it for as long as it’s fair to the user’s right to privacy and digital autonomy.  

We’re already sitting on a $2.27 trillion onchain economy.

And the more it grows, the closer we get to financial systems that aren’t just parallel experiments but real, interconnected economies. Systems that can be audited, composed, and reasoned about in ways traditional infrastructure struggles to match. RWAs are one of the paths that push us in that direction.

With RWA, you’re no longer just a smart contract dev.

You’re designing financial infrastructure and trust models that extend beyond the chain. And we need more of that.

What’s Next

In the next 2 posts, we’re going to stop talking about ideas and actually build. 

Danki will walk you through:

• what “asset-backed” really means

• the core components of the ERC-3643 RWA standard

• let’s tokenize a security! (for educational purposes only)
  
  

Just because you were able to deploy a network doesn’t make you an expert on blockchain. As a matter of fact, even an intern can do it in minutes. Here, try it.

You know what else is easy to deploy? A webpage.

Creating a blockchain is easy, and you can do it at zero cost and effort for as long as you don’t care about the design and spec of your network.

Understanding the engineering constraints to design a secure and functional blockchain architecture already takes real knowledge and skills. That’s only to get the theory right. Implementation is another thing. Yet somehow all these noise led to discussions about neither theory nor implementation. If you ask me, that’s… not a great sign.

Anyway, maybe danki iz just impatient 😌⚙️

Cryptonatives Think Everything Works like a Public Chain

From the cryptonative perspective, “using blockchain” means institutions forking their own version of the OP Stack and pretending it’s decentralization and transparency.

This is absurd.

Public chains like Ethereum, L2s, and alternative L1’s (which are privately owned chains with a wee more nodes) are engineered for open participation, fully transparent states, and global settlement.

This design is beautiful for permissionless systems… but is horrible for enterprise or government environments. It’s also why I don't recommend dumping our data and processes straight to a public chain for the sake of verifiability. Public chains are also perfect adversarial environments and are an excellent mass surveillance tool.

So, should we use a database instead? Private chain?

Maybe. You decide, compadre. But that leads us to…

The Real Work: Actually Knowing Your Constraints and Working with them

There are three challenges facing blockchain use for enterprise:

1. Privacy — enterprise data cannot be globally visible by default

2. Custodiality — access must be controlled and enforceable

3. Interoperability — systems must remove data siloes and permissionlessly extend, compose, and integrate with others. Bonus if it’s compatible with other global digital ecosystems.

And since many of you are thinking of the recent “Philippines explores blockchain for transparency” saga…Yes. Let’s design around that.

There are a few viable options, each with tradeoffs. But first:

“Can’t we just use a shared, append-only database?”

Using a database is actually great, but here’s why you need more than that:

1. For governments and businesses, storing and governing user data is a liability

Unless you’re selling data to advertisers or training AI models, storing personal data for millions of people is expensive, and dangerous because it makes you a target. Blockchains allow self-governed data through private keys. Databases + PKI can’t do that.

2. Human-operated systems is not the future of France

Humans are slow and prone to mistakes. The less manual handling, the fewer middlemen, the fewer signatures and offices, the more honest and efficient a system becomes. Blockchain provides neutral, programmable rails for automated coordination at scale.

3. Data permanence matters

Multiple diverse validators (even in a permissioned consortium) means durability and accountability. Combined with public anchors, it makes any form of cover-up difficult.

“Okay Danki, what are our options?”’

There’s no single “best architecture”, only tradeoffs.

The only rule is that we design around the constraints.

Different institutions will pick different points in the spectrum based on:

• budget

• threat model

• compliance requirements

• risk appetite

• engineering maturity

• and how allergic they are to devops

So here are your options:

Option 1: A Private Walled-Garden Chain

You use Hyperledger Fabric or Corda, throw in a few millions, spin up your validators, and create your own enclosed world.

Great if:

You have big money and want full control of the network, automation via smart contracts, and internal auditability of your processes.

Advantages:

• privacy by default

• no strangers validating your data

• smart contract automation

• internal accountability

Downsides:

• devops hell (validators, nodes, uptime, monitoring)

• zero decentralization

• zero interoperability with public chains ergo, zero public accountability

• becomes a glorified distributed database

• if you’re poor, do not attempt

Option 2: A Hybrid Private to Public Chain

You work with Hyperledger Besu or Polygon Miden/Supernets (they keep changing the name). Either way, your private chain keeps the data private while pushing public data to a public chain for accountability.

Great if:

You want a private chain but still need to prove things publicly. And you also want compatibility with global public-chain ecosystems. And you have more money to spend than the person choosing Option 1.

Advantages:

• privacy preserved

• auditability retained

• no mass surveillance

• you choose what becomes public

• interoperability with the public chain ecosystem (Ethereum or Polygon)

Downsides:

• gas fees still exist

• adversarial actors can still analyze data if insecure implementation

• devops still exists

• even worse for the budget. because now, you’d have to pay gas to the public chain on top of your private chain expenses.

Note:

pls don’t be cringe.

Publish hash commitments, NOT your entire dataset through NFT metadata. Nobody wants to accidentally leak the entire payroll onchain.

Option 3: Trusted Execution Environments (TEEs) aka Let Hardware Be Our Witness

Instead of building a private chain, you do all the transactions on a special, institution-owned hardware (a physical atm machine, computer, or vault). Assume it’s an impenetrable enclave that nobody can tamper with. Post attested results onchain.

Great if:

You want private transactions but want to post proofs publicly onchain. Security matters less than speed and cost efficiency. Probably not as expensive as options 1 and 2, but you have to trust a lot of vendors.

Advantages:

• data stays private

• very small onchain footprint

• fast and relatively cheaper

• conceptually simple, even old people can understand it

Downsides:

• you have to trust the manufacturers

• you have to trust that it can’t create a signature if it’s tampered

• enclave vulnerabilities exist (and have been exploited)

• vendor lock-in

• might be inconvenient for users to be physically present to use your system

It’s “privacy by hardware,” not privacy by design. Still valid, but choose wisely.

Option 4: Onchain Commitments with Zero-Knowledge Proofs (ZKP)

You create an identity system. Keep your database. Keep your backend chaos. Keep your entire Frankenstein architecture.

Add a module that generates zero-knowledge proofs whenever something important happens:

• bids

• requests

• balance updates

• awarding

• fund releases

Maybe even partner with banks to allow consented creation of proofs for certain accounts. Proofs get published publicly onchain. Data stays private. Verification can happen publicly or privately.

Great if:

You want to modernize slowly. You don’t expose the data to the whole globe but only to a select population who’s concerned. You just commit to its existence and integrity. You’re not ready for blockchain’s interoperability and automation, but you somehow have access to a rare cryptid dat is a ZK Engineer.

Advantages:

• raw data never touches the chain

• cheap on L2s (₱20 or less per proof)

• public accountability without exposing internals

• works with your current databases and workflows

• incremental modernization

Downsides:

• ZK engineers are costly and are difficult to find

• ZK circuits can be fragile if done incorrectly

• It’s a little slow to create proofs, though not that bad

• side-channel leaks are still possible, SNARKS aren’t quantum safe yada yada…

• requires actual cryptographic understanding and discipline

• if you don’t design your architecture to be interoperable, then it won’t be

I’m biased. But unless we invest in local cryptographic engineering education, we’ll be importing foreign crypto talents to the tune of $300k/year per engineer.

So if you actually want a Philippines that can build privacy-preserving national infrastructure… Maybe– JUST MAYBE – support Danki’s Cipher PH next year. We’ll want Filipino ZK wizards instead of paying Silicon Valley rent.

So Which Architecture Should the Philippines Use?

Hekk… that’s a tough one.

You could blend everything. You could phase it out. You could even throw darts at a diagram and see what sticks. Very on-brand for us, tbh.

If you’d ask me: Start with onchain proofs. They’re small, manageable, and low-drama. Private chains and DIDs can come later when everyone’s blood pressure has stabilized.

But I’ll favor whichever path won’t collapse under the weight of Filipino bureaucracy + budget + politics + lack of technical crypto talents.

The one that fits our constraints, our budget, our reality… not the fantasy someone saw on a conference slide deck. And definitely not the slapdash horrors that were only created out of spite.

We just need to build carefully, add tech where it actually helps, and avoid swan-diving into the deep end without floaters.

Nice and steady. Good math, low chaos. 🐴💛✨

And what brought me back from the digital grave?

Larpers. Everywhere. People posing as crypto 'experts' when they haven’t done the actual work of researching whatever the hekk it is they are talking about. It’s all vibes and appearances and no substance.

Lately, the Orb and World has been made an antagonist in the Filipino crypto scene. And everyone suddenly became a data privacy expert and morality champion overnight.

But y’all… the code is literally open-source. Public. On GitHub. Verifiable and transparent. Yet most of the noise came from people whose deepest technical dive was into Tiktok, probably. I mean opinions are fine. Sure, pop off. But when you're out here spreading crypto misinformation like it's your side hustle, that’s not just lazy. That’s lying. Please don’t do that, it’s bad.

Anyway, because nobody’s doing it, Danki went through World’s codebase to dissect and translate it for humans. But first…

Why do we even need PoH?

We are entering a phase of the internet where:

• Bots have social media accounts

• Bots make video calls and phone calls

• Bots make fake IDs

• Bots have crypto wallets

• Bots can vote on-chain

• Bots have fans clubs

My fren, it has become normal to not know whether you're reading content from a person or a language model. It’s already bad. But it’s gonna get weirder.

AI systems are already powerful enough to influence, deceive, vote, and even transact like humans. It’s already anarchy, albeit one where you only detect the tip of the iceberg.

My point being.. Proof of Humanity, or a system that makes it easy to prove that you’re a human is going to impact people who don’t even know about crypto.

Just some ways that immediately come to mind:

• Preventing Deepfakes: Video calling and communication platforms can integrate PoH to make sure that the user is talking to a real human.

• Pseudonymous Communication: You can even prove humanity without doxxing who you are

• Aid distribution: Not saying it’s UBI, but any aid system can eliminate ghost beneficiaries, fraud, and identity duplication through PoH.

• Secure KYC over the Internet: You don’t have to travel miles and queue up to register a government ID. If you have a valid PoH then it will be possible to do it at home.

So as you can see, it isn’t just some crypto flex. It’s more like a universal captcha but one that cannot be ‘outsourced’ and one that doesn’t annoy u by asking to find traffic lights in 144p JPEGs.

Now, going back to the code.

++++++

How the Orb Actually Works

There’s a large codebase, but here are the main components you can look into if you want to know what the system does to your iris scan:

• open-iris: a pipeline that converts raw iris images into iris codes (has three parts: segmentation → normalization → feature extraction).In human language: It takes note of your iris’ features and extracts those to generate a binary code that serves as your identifier.Open Iris Repo

• orb-software: Orb Software Repo

  • orb-core/do_signup calls image capture, iris processing, then signs iris codes and sends them to the backend uniqueness service, which is closed-source (bleh)In human language: It calls all the code needed to process your iris data and signs it to make sure everything came from the orb and not somewhere else

  • orb-secure-element & orb-attest modules that generate hardware-backed attestations; the backend validates these signatures. In human language: It shows how your iris code data is encrypted both at rest and in transit.

• signup-sequencer: takes your identity commitments, or 32-byte hashes that were produced after an iris is verified and updates the Merkle Tree. In human language: Generates a ZK proof that says “this person was added to our list of real humans”. This ZK proof will not tell who you are or where you scanned or what your iris code is, nothing. Just that you were part of the listSignup Sequencer Repo

Ok, now let’s begin with the lines we’re most concerned about:

Do they delete the iris scans? Yes. But not by calling a delete() function. The Orb processes iris images entirely in memory and (because this is written in Rust) it discards it automatically right after use.

let frame = eye_tracker.capture_frame().await?;
let iris_code = compute_iris_code(&frame)?;

The image variable is processed in these lines, but never written to disk or saved.

I asked my AI to scan of the codebase for any file I/O routines (File::create, fs::write, etc.) during the processes in the Orb-core pipeline. Looks like there’s none. So they’re really not saving it.

Then what are they getting from the scans?

An iris code that looks like a nonsensical bunch of 1’s and 0’s. You can check the open-iris repo to see how they transform it. The binarization algorithm is explained here in a more understandable language, but you can knock yourselves out analyzing the code here and here.

Do they even save that garble of a binary number that is your iris code? Also no.

They only use it to check whether you’re a unique human being. They split it up into three parts and use SMPC (Secure Multiparty Computation) to compare chopped up shares of it with all the chopped up shares of the other iris codes that were ever created. Do note that this part is closed-source. But it’s still nice to read their paper about large scale MPC.

There’s no more need for that iris code once your humanity has been proven. This is where ZK comes in. The iris code is made into a commitment hash through a (boo) another closed-source but audited code by Trail of Bits.

Now your commitment hash is hang by the Merkle Tree, any application that integrates with World ID can verify the proofs generated by your account.

Side: I would personally trust Trail of Bits because they’re one of the reputable auditing names out there (and they basically taught me how to fuzz test), but to each his own.

So let’s go back to what these clout-chasers were saying:

“They're storing my sensitive iris data to do whatever the hekk they want with it!"

No, Chad. They don’t even have your iris code. What they have is an encrypted representation of the existence of your iris code. Which can’t be unhashed by anyone, not even by World themselves.

If you can follow the flow: no biometric data stored = no breach of trust. Unless you plan to sell your fingers, phone, and World private key to the same person on Facebook Marketplace, nobody's getting anything from anyone.

"But they're going to sell the data they got through the Orb!"

An even spicier conspiracy. What will they sell? The commitment hash of the existence of your iris code that not even them can decrypt? Who’s gonna buy that Chad?

"Then why are they buying my biometrics in exchange for tokens?"

Okay, I get it somehow. But here’s a reality check:

• Most people don’t know why everyone needs PoH

• Most people don’t know how Web3, PoH, or even single-factor authentication works.

• But they all need the protection that PoH provides.

Not everyone has to understand combustion engines to ride a bus. They just need a ride.

You can’t onboard 8 billion people by giving them a 5-hour cryptography lecture. So what do you do? You incentivize adoption.

It’s kind of a lesson in game theory. If you can’t convince the granmas to care, then flip the incentives. Make doing the right thing the easiest option. World is not paying you for your data. It’s rewarding you so that you would participate.

"They're using politicians to get people to scan their eyeballs!"

LOL. Bro. Danki tries to be an honest, accurate, kind person with integrity. But guess what wins people over most of the time? Appearances. Loss aversion and chasing incentives. You think people lined up for an Orb because they read the World whitepaper? No. They heard they’d get free money.

And yes, politicians got involved. Is that ideal? No. Is that efficient? Yes. Is it dangerous? Only if they can tamper with the Orb.

Which leads me to…

"Can somebody tamper with the Orb to get my original iris images?"

Yes, but it’s extremely difficult to do so undetected. There are many layers of detection in the orb:

• The open-source orb-attest component interacts directly with the Orb’s secure element, which holds private signing keys in a tamper-resistant hardware chip.

• Measured Boot & Orb OS - closed source but if we’d believe the README, it uses secure enclave and secure element for key operations.

• The orb-firmware project includes tamper-detection logic and secure runtime that monitors hardware tampering, power glitches, physical access, etc. It’s undisclosed and IP’d but that’s understandable.

Anyway, spending this whole night reviewing World's codebase is like reading an autist's work. There's no effort to dumb things down so that the general public can understand, because they know the average person won't even try. But I’m blown, the amount of thought and detail put into its design is interesting.

“But what if they deployed something different from what’s in the repo?”

Could be the case. But it's too much effort to construct a very complicated system with hundreds of commits and multiple deployment signatures, all just to cover a lie. I would have stopped at giving cash for iris data. But nah, they went full nerd.

Now, if you'd still like to throw arguments against cold hard code, let me help you, here are some suggestions for a more believable counterpiece. Despite multiple opportunities, da danki herself hasn’t put her eyeballs anywhere near the Orb.

So Why I Still Haven’t Scanned + Why I Might

Because I do have a few legitimate questions, and it’s okay to be skeptical if your skepticism is informed:

1. What happens to the encrypted iris code after it gets sent to the backend for uniqueness checking?

   Hamming distance comparisons via partial key shares are cool and all, but who are the entities running the three MPC nodes? If they’re all affiliated with World, then yes it's cryptographically secure, but not decentralized. And in that case these three entities can collude to reconstruct all the iris codes that were ever created.

   If the MPC protocol and architecture is open-sourced and shown to have sufficient decentralization, then I’ll feel much safer about it.

2. What happens if I lost my World ID, can I regenerate a new one via my previously scanned eyeballs?

   I think there’s no answer to this yet, but Danki would love some clarity.

3. What happens if you want to delete your World ID?

   Spoiler: because it’s a protocol and I don’t see any code or mention of a component that will delete your PoH, you probably can’t.

I Just Can’t Fear the Orb If It’s Opensource

World is not perfect. But it’s trying. And it’s doing it in the open. You know what’s worse? All these other KYC systems in the planet hoarding your data in privately managed servers, then leaking it in some sketchy DeepWeb dump.

Sometimes saying you don’t know and asking questions is a more pro move than making up stories and building on clout. And before you spin things at least check the source.

I’m touching grass now. Hope the world heals. Hope you lerned something. 🐴

Now after a few traumatic attempts at understanding the old version of Cairo (excuse me I’m quite normie), my fear was that the addition of this new steps will make it more complex, but luckily I was proven wrong.

A Quick Rundown on How Cairo Works

Cairo is specifically designed for creating validity proofs, and for this reason it compiles to a special machine code they call CASM which translates to a set of polynomial constraints and runs on a VM that was optimized for proofs (aka. Cairo is not an EVM Compatible language).

Cairo VM is different in a few ways from EVM, like for instance, field element is the only data type in Cairo while we have a variety of 256-bit words for EVM languages like Solidity which we still have to emulate into field elements if we’re going to run proofs, so why not just go with it directly. Anyway… what makes proving multiple times faster in Cairo VM is their read-only memory model. Linear type systems like this also guarantees safety when it comes to making sure that memory cannot be deleted or rewritten.

So we’re trading off composability for efficiency aren’t we…

This probably one of the bigger downsides of using a proof-optimized system, I think. Because Cairo is made to run on a different VM, we can’t just create dApps with it that are interoperable with protocols in the EVM, which is a big bummer but luckily we now have Kakarot, a enshrined zkEVM implemented in Cairo that can serve as an abstraction layer for programs written in Cairo, practically enabling EVM calls and Solidity bytecode to be interpreted in StarkNet. It is still not live in production as of time of writing, to note. But I’m looking forward to try the RPC and will post about it.

The Dawn of Sierra

So with the original Cairo, the compilation goes like this:

Cairo --→ CASM

Where Cairo compiles locally into CASM (Cairo Assembly) which is a machine code that translates to polynomial constraints. So every program written in Cairo generates a proof of correct CASM execution and that is then sent to the StarkNet sequencer.

This process has some nuances though. For example, if the user submits an invalid transaction in CASM directly to the sequencer and it reverted, then there will be no proof generated that the user has indeed submitted a failed transaction so that the network can collect fees from it. And if StarkNet can’t collect fees for doing certain computations then it can be an opening to DoS attacks in the network.

So now we have to introduce a safe form of CASM that will be provable at all times, and that is where this intermediate representation, Sierra comes in. In Cairo 1.0, the program first has to locally compile into Sierra which then compiles into safe CASM when submitted to the sequencers for verifying. This means can no longer send CASM directly to StarkNet, limiting the attack surface and making the network more secure.

The compilation process in Cairo 1.0 looks like this:

Cairo 1.0 --→ Sierra --→ Safe CASM

Some other notable features of Sierra include:

-Gas counting upon compilation to Sierra. Sierra makes sure that each function counts its gas correctly and returns if it has reached the limit.

-Intermediate representation enables type information from Sierra to work with native types, opening the possibility that StarkNet sequencers may eventually run on native hardware

Why Cairo 1.0 Syntax is Easier to Use

When I first encountered Cairo, you will still have to create types for different integers and addresses using field entities or felt. And then I had to understand when and how to use variable declaration patterns like tempvar, local… Tbh it’s a little overwhelming for noobs like me, but it gets more understandable now because some of these low-level decisions are now abstracted away in the language.

There are many examples where I can point out that it’s looking more like Rust and is easier to the eyes, and here are some:

• func is now just fn, and its return variables no longer have variable names but just their types.

• @storage_var is no more, now you have to put them in a storage struct, write the contract traits, and then write its implementation.

• the decorator syntax is now more Rust-like. So is creating enums and matching patterns

• the use of an interface contract they call traits, which has a separate section for its implementation

• enabling type generic parameters through the use of <>

• easy upgradeability by just replacing class hash!

There are many more that I probably missed, so better check out their docs.

As y’all know, I come from a Solidity background and still currently exploring Rust. So if you’re interested, let’s be scruffy, learn from mistakes together, and take this path with me! I’ll be hacking away a few sample programs in Cairo 1.0 and hopefully get to share some with you, too.

Some years ago, we expect one single blockchain to perform various functions for us. For instance, Ethereum has become congested because it was juggling between validating incoming transactions, arranging them into blocks, executing them, and finally keeping all these growing records available at all times. That was a lot of tasks. And it slows down the network. So Layer 2’s and sidechains were made to decongest it by delegating the task of computation for L1s and then pushing the result of multiple transactions within a single transaction to L1.

Sounds simple. And then we ask clarifying questions like, how do these L2 solutions prove to L1 that the transaction they process is actually valid? That’s how we get to proving systems, and there are two types:

1. Fraud Proofs

   Fraud proofs are used by optimistic rollups. Optimistic rollups just assume that all transactions are valid and pushes them to their block, which sounds a little crazy but is actually secure because there are fraud proofs. There will be a time window for anyone to challenge the block made in L2 before it becomes accepted in L1.

   To challenge a transaction’s validity, anyone can compute a fraud proof which is basically a proof of mismatch between specific parts of the merkle tree and the condensed data on the merkle root. When a fraud proof is accepted, the rollup simply re-updates its state and the block builder who included the invalid transaction gets a penalty.

   You gotta note that we require that data from L1 be accessible to L2 in order for challengers to produce a fraud proof.

2. Zero-Knowledge Proofs

   Zero-knowledge rollups also bundle up transactions and summarizes their blocks to L1. But unlike fraud proofs, validity proofs don’t need a challenge period to finalize state changes. It uses zero-knowledge cryptography to prove that the changes being pushed to L1 is indeed a result of executing valid transactions made on the rollup. Once the validity proof is submitted to L1, then the state changes are instantly accepted.

   Now this wouldn’t require any access to L1 data, because they are merely sending a proof of computation that happened within the zk rollup.

   There are many cool ways to design a zk rollup, and there are many flavors of this cryptography to choose from (eg. SNARKS, STARKS, etc.), but I would have to write the comparison in a separate post. Hekk, I might wanna write about how a typical proving circuit in zk-rollups look like. But moving on…

You might notice that data availability is sometimes an issue if the historical transaction needs to be proven as valid by other chains. But storage in the blockchain is expensive, and nodes have to continuously store a growing history if they want to make the data available. So to give us options, we have at least three types of L2 solutions:

1. Rollups – a layer that executes the transactions and then sends a proof AND a record of all these processed transactions as call data to L1.

2. Validiums – only executes the transaction and sends a proof of validity to L1. Incredibly cheap but has a chance of locking your funds in the validium. Great use for not-so important transactions like on-chain games.

3. Volitions – lets the user decide whether to use a validium or a rollup for their transaction.

And then there are also sidechains whose history is separate from the L1 and has its own consensus model (they don’t do any proving to L1 and don’t inherit its security). Sidechains are merely connected to L1s by a two-way bridge that can move assets between the chains.

Ok folks, that’s the execution layer. Now people can have the option of faster transaction processing through these L2s. Although with this design we are still putting strain on L1 because it has three jobs to do: making the network agree on just one version of truth (the blockchain’s state), deciding on how to sequence the transactions, and storing all that transaction history. We’re gonna be munching on these next, but for now GN!

• Most blockchains today rely on elliptic curve signatures (like ECDSA/EdDSA). These are not post-quantum secure. A sufficiently powerful quantum computer could forge signatures and spend funds from exposed keys. This is probably where they’re coming from.

• Hash functions like Keccak256 (used in Ethereum) are more resilient, even under quantum attacks. Grover’s algorithm weakens them, but doesn’t break them outright. So no, a quantum attacker doesn’t just rewrite chain history or magically “undo hashes.”

• This means the real risk is key compromise, not instant consensus collapse. But note: signatures are also used in validators, bridges, multisigs, etc. so it’s not just wallets.

• Blockchains are not static. They can upgrade. Ethereum alone has already coordinated massive changes (see: EIP-4844, account abstraction direction, etc.). Migration to post-quantum signatures is hard — but very doable with enough lead time.

• Post-quantum cryptography isn’t hypothetical. We already have standardized schemes (like lattice-based signatures from NIST). The problem is efficiency and integration, not existence.

• ZK systems are a mixed bag. Many SNARKs today rely on algebraic assumptions (pairings, discrete logs) that are not quantum-safe. Most of today’s widely used ZK opt for statistical zero-knowledge over statistical soundness… which means a quantum adversary may break soundness in terms of deriving toxic waste from a trusted setup ceremony and fake a ZK-SNARK. A strong enough quantum adversary could forge proofs in some setups. STARKs and hash-based systems are generally more post-quantum friendly.

• Also, please stop quoting raw qubit numbers like it’s a countdown timer. Breaking ECC requires error-corrected (logical) qubits, not the noisy ones you see in headlines. We are not there yet. Not even close.

Now there are a lot of ways quantum computing can potentially break the blockchain. But right now it’s mostly a migration problem, not an extinction event.

As for me, I’ll only start panicking if someone figures out how to efficiently reverse hash functions. I don’t think it will happen though. But to each his own.

Ok now go, have better discussions about post-quantum cryptography in da blockchainz 🐴

We’d be talking about one of the most controversial protocols in DeFi and how ZK was used for its privacy-preserving properties: Tornado Cash. Do you know one of the founders of got jailed for it… fortunately he’s already released as of today-- just with a monitoring device on his ankles. Gomsh.

So anyway, I’m gonna talk about how the protocol works under the hood and maybe add in some ideas on how mixers kan be built better so you can prevent bad elements from using the protocol while avoiding being put on a human cage for trying to preseve everyone’s privacy.

Wait. Disclaimer: I don’t by any means encourage illegal activities in the blockchain. And if you use Tornado Cash or any similar mixer, there is a good chance that some protocols and centralized exchanges might blacklist your wallet. This is purely for educational purposes only as Tornado Cash is one of the first ZK-powered dApps that gained popularity among privacy-conscious users.

How do Mixers work?

A mixer is a special type of smart contract that takes in deposits from different users and allows a different address to withdraw from it without revealing from whom the deposit came from.

Well, not really. If there are only a few people who deposited into the mixer, then it’s fairly easy to guess from which address you’re withdrawing. That aside, the closest TradFi equivalent for this would be a bank’s safe deposit box with a lot of people going in and out of the room. In a safe deposit box, anyone who has the key can access whatever is stored in their safe. And while it’s easy to know who withdrew from which deposit box if only one person ever goes in and out of the room, it will be harder and harder to guess if many people frequent the room.

There are other custodial mixers in the space, but Tornado Cash is unique because it is totally permissionless and decentralized. You only get to withdraw the tokens you deposited and not a combination of tokens that were relinquished to the protocol by other users and was mixed by a centralized authority.

Just by throwing around these ideas, it’s not hard to imagine how Tornado Cash became a tool for hackers to withdraw the crypto they obtained thru nefarious means. I’ll be sharing some ways on how to prevent this from happening later. But first, our ZK lesson…

Tornado’s Trusted Setup

The protocol uses a ZK-SNARK based library which, if you remember from a previous post, goes like this:

1. The circuit has a trusted setup which is an algorithm that the verifier uses to create non-interactive proofs

2. In the setup, the prover has to pick a random number to evaluate from. This answer is run through a hash and becomes part of the proof. The other part of the proof is obtained by having the hash evaluated through another function in the Fiat-Shamir Transformation.

Now, in Tornado, the depositor picks two random numbers k and r : k being a nullifier whose hash will be used to make sure that no token can be withdrawn more than once, and r is another random number through which we’ll evaluate the algorithm. These two numbers should be private at all times because they’ll be used to withdraw the deposited funds anonymously. The withdrawer then runs both numbers in a hashing function S[R, h, A, f, t] to prove that he knows the values of k and r.

Wait whut iz R, h, A, f, t you say?

They are all public variables.

R is the merkle root of the tree we’re withdrawing from

h is the hash of our nullifier k

A is the recipient address of the deposited token

f is the fee the recipient pays to the relayer address

and t is the relayer address

Now, here’s how the prover computes:

**S[R, h, A, f, t] = {I KNOW k, r ∈ B 248, l ∈ B 16, O ∈ Z 16 p **

SUCH THAT h = H1(k) AND O is the opening of H2(k||r) at position l to R}

Ok, we have a new variable O and l. Simply put, O(T , l) is the Merkle opening for leaf with index l, and T is a merkle tree with a height of 20. You don’t have to worry much about it, it’s just a way of verifying that there’s a node in the tree whose deposit can be unlocked by values k and r.

If you would notice, there is really no A and f in the equation above. But adding them in the hashing function is actually a thoughtful move because while these variables are not a necessary part of the computation for the proof, having the recipient address and fee in the hash can prevent a frontrunning attack by MEV bots.

Anyway, from these variables we’ll compute for two values again and by the end of the process we’ll have two public parameters: dp and dv which will be used for constructing the proof and the verifier respectively (I won’t go into detail anymore as the functions for computing these params don’t seem very important, but you can read here).

When a proof is successfully submitted to the Tornado Cash contract, the tokens are released to recipient address A, the relayer fee f is released to relayer address t, and the nullifier hash is added to a list of hashes that have already been used (to ensure the proof cannot be reused to withdraw).

Ok that was some knotty process. Though believe it or not Tornado Cash is one of the simpler ones. It was still dangerous tech tho, so I am also suggesting some ways we can have a privacy-preserving dApp like this while keeping it free from illegal activities.

Ideas on How to Make Mixers Less Sketchy

The good news is that the web3 landscape is no longer the same as in 2019 when the Tornado Cash whitepaper was published. We have a lot more advanced ways of verifying identity and activities on-chain. One such ways is using DIDs or decentralized IDs to prove that the user has not been on any sanctions list, blacklisted by any blockchain security company, or has not made any red flag transactions before allowing them to deposit into the mixer.

Easier said than done. As y’all know, computation in the blockchain is expensive and it might take a lot of gas to do this. Or we might need an oracle but it might beat the purpose of preserving user privacy.

A more decentralized way of tackling this is to give the withdrawers the ability to prove that they are not linked to a certain address (without revealing anything else about them). This enables law enforcers to narrow down the addresses who are probably withdrawing funds obtained from criminal activity.

And if you’re someone who’s planning to use mixers for shady reasons, know that they are not an end-all-be-all to transaction privacy on chain. There are so many ways you could give away your identity while using these protocols but I deleted the section so good luck in der haha.. If you’re a cybersec and wanna lern how to catch em, contact Danki and I’ll give away some secret movez.

Up Next

Em not very satisfied with the fact that I haven’t yet explained how we even get these equations to begin with. So the next ZK post will be about how we turn literal programs into a ZK circuit. You’ll be meeting Quadratic Arithmetic Program, R1CS, and the many stages of turning regular programming logic into a ZK-Proof. Might even do a demo on Circom but I can’t promise yet as I’m so hung up on debugging ZK programs.

For now I sleeps and recover. Bye frens!

The protocol iz Pendle Finance. Most crypto apers miss this because admittedly the barrier to understanding what it does is high. But I think it’s a hidden gold mine just waiting to be discovered by the wider crypto public.

So… here we go. Pendle Finance is the DeFi counterpart of the $400T interest derivative market. By that, I mean it enables you to trade the fluctuations of interest rates.

In staking, you got this thing called APY that tells how much interest you’re getting for your crypto. But APY is not set in stone. A protocol may say it will be giving you 69,000% APY but only give you 6% by the end of the period. This is because APY changes depending on the supply and demand of the token you’re staking, how diluted it becomes, and even on how many participants are staking. So rather than just praying that you’ll get the promised yield for your staked crypto, you can actually trade the yield proactively on Pendle and have more control of your staking earnings.

Twin Balls: The Yield and The Principal

It all begins by splitting your staked token into two: the Principal Token (PT) and the Yield Token (YT). The PT can be redeemed 1:1 with your underlying token once the maturity date has been reached. Before maturity date, you can buy PT at a lower price and it will increase in token value until you can exchange it equally with the real token.

YT represents the yield for each underlying token. So if, for example, you deposited 5 staked ETH that has 5% APY, then you’ll get 5 YT to represent that 0.05 ETH yield for each token. If you wanted to short the interest rate, you sell some YT back into PT. But if you wanna bet that the APY will go higher, then you buy more YT. Say, you’re bullish that ETH staking rewards will go higher. You can just buy 100 YT-stETH and now you can get the increasing yield for 100 stETH without actually needing to buy 100 ETH.

But what’s the relationship between the PT and YT? Remember when I said you can buy PT at a lower price before maturity date? Well it gets that discount from the APY of your staked token. And since YT represents the APY from your staked token which you’re making redeemable through PT by the end of the period, YT loses its token value as time passes until it becomes zero at maturity date.

In short, the values of PT and YT move inversely correlated to each other over time… pretty much like lato-lato balls converging again after being split in opposite directions.

If you’re OC, here’s the exact formula for the relationship between the two tokens:

P(PT)+P(YT)=P(Underlying)

Now you know the rules of splitting. Jast keep lato-lato in mind because there are huge advantages to using Pendle that you can’t get anywhere else:

Fixed Yield Strategy

Pendle’s design enables participants to lock in the yields for their staked tokens. As you olredy know, the yields in your staking protocols are unpredictable and you never know what you’re gonna get in total. Dis causes headaches and uncertainty.

But remember, if you buy PT at an already declared APY (its implied yield), you are always guaranteed of the exact yield you’d be getting by maturity date. So how to lock in your yields? Just buy the PT of your choice token and hold til maturity date. Tadaaa, fixed yield.

PT Trading vs Spot Trading

Spot trading iz nice and all, until I realized you can also trade PT like they’re spot tokens. It does make sense because the value of the PT moves in parallel relative to its underlying asset. But compared to spot, PT also has a guaranteed fixed yield. The token literally multiplies. So if I ever make a losing trade, at least I can get some yield from holding a PT. And if I make a winning trade, I still get additional yield to sweeten the win… so, it’s really a no brainer decision to use PT to trade whenever possible.

Liquidity Providing with Zero Impermanent Loss

This is probably my favorite. Pendle pools are pretty spooky because you always know how it ends up on maturity date: you get back your investment at the same token value. This is because PT is equal to your underlying asset by the end of the period. And if they have the same value, then there will be no impermanent loss eventually.

How do you use this to your advantage? Well if you’re just planning to hold a staked token for a long time, you can get free money by putting it in Pendle’s liquidity pool and earn incentives, swap fees, PT yield, as well as staking rewards. All that is risk-free, because read the previous paragraph anon. I can’t be any more excited for staker frens 🐴💖

A Use Case for Simple Personz

Us plebs may not even want to trade interest rates or participate in liquidity pools. It still has some use for us though. Say danki wanna buy ETH and is planning to hold it for the long term. I will likely get the best discounted prices at Pendle, because PT haz yield. The catch is that I can only redeem them at a later date, but since I’d be holding the tokens for a long while anyhow, the waiting time wouldn’t matter.

Buying PT can actually serve as a big discount voucher to any token you wanted to buy and hold. Simple enough if you just wanna ape :D

Another DeFi Poetry

As you see, the token-splitting mechanism that started it all seems very unique, and that is because it has its own token standard. Once a yield-bearing token is provided to Pendle, they create an SY token behind the scenes which is what the protocol uses to interface with the original token you provided. From there, they mint your PT and YT.

The interesting thing is that SY tokens might have a use outside Pendle because it literally made a standard interface for protocols to interact with yield-bearing tokens in a generic yield-generating pool. It might eliminate any protocol’s need to use custom code when dealing with the special mechanisms of these pools and yield-bearing tokens. I might go back to this in detail in the future!

The AMM is interesting too… since we’re trading yield, the range gets pretty narrow and predictable and the model almost mimics a concentrated liquidity pool. So the trading range is easily set and the users benefit from lower price impact and better capital efficiency for LP-ers.

I kan sense some frends’ brainz are screaming olredy. It’s normal tho, Pendle is one of the more unique protocols I reviewed. Danki almost cried from trying to understand some token splittin mechanisms haha.. But we made it! We have a detailed explainer of one of the most novel DeFi protocols that I think is gonna be big in the future.

I hope you lerned something. Next time I want to talk about primitive pools where the liquidity curve dynamically changes over time. Or maybe I’ll just donkey around and write something lighter and funnier. Whatever it is, thenks for hanging out in here. Ciao!

I’m here to tell you that both are true. And I’m not gonna pretend that Web3 is a utopian dream where only good projects emerge because that is simply not the reality of it. Web3 is a tool… it can be used for either good or bad and a lot of gray areas in between. But it is one powerful tool, so today I’m going to dissect what makes a ‘good’ use of this technology.

Before I make this explainer, let’s make sure we’re on the same page and are talking about the same thing:

What Web3 is NOT: cryptocurrencies and crypto trading. While cryptocurrencies are a part of the space, web3 isn’t an uber-bullish notion that every token must go up in value. Ask yourself deeper questions before you get hyped, “What is the utility of this token and why are people buying it?” Sometimes it only takes a few probing questions to realize that a lot of these projects are only built for the sole purpose of making money for its creators and early investors without bringing any benefit for the greater public.

Ok, now we’ve gotten that out of the way, let’s try to define what Web3 is in the context of previous internet functionalities:

Web1 - A read-only web. This is how the early interned was initially intended to be. There are static websites to disseminate information but there is no participation from the user.

Web2 - A read-and-write web. This is where things started to explode because now the user is not a mere passive consumer of information but a source of data. Users can now post their content, get tracked for their activities, and have unique experiences inside the platform they’re in. The problem is that all these data can be accessed and sold by the companies who run the centralized servers from behind.

Web3 - A read-write-and-own web. A new internet paradigm where users can own digital assets (which can be anything from game items to one’s own identity) through their wallets. Instead of relying on centralized authorities, the system runs on code and these code utilize mechanisms and game theory to consistently incentivize and punish behaviors that are beneficial/detrimental to the system.

Danki’s Back Story

I hab a bad back. Even as a kid, I slump while I walk. And while I always get good grades in school my posture gives away the fact that I’m not always sure of myself. Couple that with lack of social skills and the involuntary smile whenever I’m uncomfortable, and you got the perfect recipe for being the least believed person practically anywhere you go.

Why am I telling this?

Because the aggregate of these experiences is how I got sucked into Web3. In a centralized world, people make the judgement. And while most of the time they don’t act out of malice, their judgements are always prone to biases and fallacies leading them to bad decisions. So I learned the hard way that it is in everyone’s best interest to make a system that doesn’t rely on a central authority’s judgement, but instead uses an architecture where the rules are clearly laid out and are executable, and authority is distributed.

Web3 offers a dream for donkeys with bad backs. Finally, we have a mechanism that doesn’t rely on mere trust and beliefs but on provability. Blockchain and decentralization enables anyone in the network to objectively verify things and have everyone subjected to the same hardcoded rules without special, subjective exceptions.

More Than Just the ‘Tech’

Betting on web3 and blockchain technology is a bet for everyone’s need for transparency, self-sovereignty, and inclusivity.

In this world full of breaches in user privacy, where all the things you posses are at the mercy of centralized authorities, where deepfakes can easily be used for mass deception… we all need a little decentralization and ownership to bring back this imbalance of power to a healthier level.

That being said, these are the things and concepts that I think represents the role of Web3 in disrupting the way things are done today:

Decentralization

A centralized system is only as good as the one who holds the decision-making power over it. While centralization itself is not a bad thing, there are certain cases where it is better to have this power and ownership distributed among the users, builders, and stakeholders to align the incentives and risks to the actual decision making process.

Permissionlessness

Permissionlessness means that everyone has equal access to the system as long as they follow its rules and that there are no gatekeepers to censor who can be part of Web3 and who cannot be.

Trustlessness

This property of Web3 enables people to be part of the same system without needing to trust that the others will cooperate. How is this made possible? By utilizing game theory and mechanisms to incentivize honest behavior and punish the malicious ones.

Ownership

When you truly own something, it means no one can take it away from you without you giving it away. Ask yourself: do you truly own your data if your platform or service provider can easily sell it and use it without your knowledge? Do you truly own your money if your bank can close your account any time? Do you truly own your digital creations if they can easily be copied and reposted by anyone? Web3 solves the ownership problem by having all your digital assets singularly managed inside your own wallet.

Immutability

Immutability means that something is irreversible and cannot be tampered with. The history of the transactions in the blockchain cannot easily be changed in any form by anyone with a vested interest. Doing so would require an attack so expensive, it will be totally impractical.

…And these things, mah frens, iz why Web3 is such a big playground that continues to fascinate a lot of people. It’s not always because of the money. When something about these concepts resonate with your own values, it will be unavoidable to get sucked into the space.

Can you feel the pull now? Give in. It’s a deep, crazy rabbithole down here, but it’s worth the jump.

So from these inefficiencies, DEXes are born. And safe to say that as of the moment, the most popular DEX that is catering to hundreds of thousands of crypto users is Uniswap.

This has been one of my autistic obsessions. Uniswap’s upgrades have always marked something new for DeFi. And now we’re on v4, it seems that the exchange has matured to a point that it may truly be able to cater to sophisticated market making strategies that are usually only found in TradFi.

Warning: Long post ahead and may involve some math. Do not read beyond the asterisks if you get seizures from seeing graphs and formulas.

********

Uniswap v1: ETH-Centered Swaps

At this point DEXes are just dawning and we have a simple market maker that uses the ubiquitous x * y = k formula. The most prominent characteristic of V1 though is that it only allows for swap between native ETH and another ERC-20 token. So, if say you want to swap your USDT for some MATIC, then you will have to go the route of swapping USDT to ETH, and then swapping that ETH to MATIC. There is no getting around it. You pay double fees just to make that trade, which iz sadt. And slippage sucks because there is no way to read what is happening on the other pools to find the most cost-efficient way to trade your tokens. And that is how V2 entered…

Uniswap v2: The Birth of Routers

Uniswap V2 fixes problems from V1 by giving the users the ability to create a custom ERC20-ERC20 pool, do a direct swap inside that pool, or use the Router.

Ok that’s new. Since Routers were introduced, we now have a smart contract that can look to every liquidity pool contract that was permissionlessly created using Uniswap V2 protocol. It enables users to choose the “route” of their transaction. For example, somebody may opt to swap their USDT for MATIC through the USDT-DAI / DAI-ETH / ETH-MATIC route. It may sound crazy because who in their right mind will complicate the routes of their trades, but this is especially useful for arbitrage which is a technique MEVs use to profit from price discrepancies between pools. I’ll have a separate article for this maybe, but no promises. The important thing you need to know is that arbitrageurs help these pools become more liquid so the slippage is lessened when you make a trade between less common tokens in Uniswap.

There are actually many updates in V2, but I’ll only talk about one more coz we’re gonna hang around V3 and V4 much longer: V2 now has an on-chain oracle price feed.

This improvement is not actually for Uniswap direct users but for other markets and protocols that will use their exchange prices as basis for transaction.

Anyway, the problem is that many pools in the Uniswap fluctuate wildly, and they’re not even hard to manipulate because you can easily borrow millions of dollars from a flashloan. The attacker can use an arbitrage bot to pocket the discrepancy from the real price. So wat did Uniswap do?

V2 then made the oracle to measure prices at the end of the block so that any manipulator wouldn’t be able to arbitrage to their choice of protocol without first making a bad trade in Uniswap at the end of a previous block.

Anyway, after a block is mined, there will be a few seconds before the next block comes. This elapsed time will be measured and then multiplied to the end-of-block price (and now we have the time-weighted price). And the process starts again on the next block. You simply sum these time-weighted prices up for whichever time interval your external contract wanna measure.

A little visual to illustrate TWAP math:

Notice that we’re simply computing the average price movement like normal, which is the cumulative price on that period over the total elapsed time. You will later on learn that this is not a very accurate formula when you wanna compute for the average change in price in terms of percentage (and not numbers).

Uniswap v3: Range-bound Liquidity

I’ve waited like 3 posts to talk about this LOL. V3 is my personal favorite upgrade because it’s solving a huge problem in capital efficiency and at the same time, it has opened new market making strategies aside from just passive liquidity providing.

Remember the problem I’ve mentioned in Constant Product Market Makers? Well, those liquidity distributed at extreme prices may never be utilized. So, V3 introduced concentrated or range-bound liquidity where liquidity providers can pick at which price range they are willing to provide. Now they can find themselves always in the middle of the liquidity graph where most of trades happen and consequently where most of commissions are earned. And it benefits the user too, because more liquidity in their trading prices means less price impact on their trades.

This design has opened some new questions though because the liquidity will be irregularly distributed across this curve. For example, how will Uniswap even compute for the exchange rate? Surely, we can’t just x * y = k the whole thing to compute for the price in any arbitrary point in this curve. And how do you even determine at what exact values can the liquidity be placed?

I scratch my earz, cause we’re getting to ticks. Just take a look:

These little markings along the liquidity curve represents a price point that you can use to either define which price you can place an order, or define the range where you can place your liquidity. Imagine ticks like a pixel on your computer. You can’t have two colors inside a pixel the same way you can’t have two different liquidity in between ticks.

So, basically, you have a definite k value in the x * y = k for each space between ticks.

The catch is that ticks are not expressed in terms of currency. They are a different unit of price, because ticks and their spacing still have to be initialized and determined depending on the fee tier of the pool.

So, how does Uniswap compute for the tick and how can you convert these ticks into a price value?

The relationship between the price and tick is this:

Tick = log1.0001(Price)

Don’t let this formula intimidate you tho, it only means that each tick is the power that you have to raise 1.0001 to in order to receive a certain output price.

If we rearrange this formula to get the price at any given tick, then it looks simpler:

Price = 1.0001^τ

Uniswap pools always have a range of ticks between -887272 and 887272, which equates to 2^-128 to 2^128 in price, which is practically 0 to infinity and covers the whole range of possible prices.

But it is not advisable to use the Price = 1.0001^τ formula in computing price because of precision loss due to integer constraints. So we have a variable called sqrtPriceX96 to compute for price.

Without going into much details, sqrtPricex96 is exactly what it says: the product of the square root of the price and 2^96 (as it is expressed in bits). Why this formula tho? It was the largest value for precision that allowed for the best gas efficiency.

Anyway, going back to concentrated liquidity... If you’re a degen looking for market making opportunities, you have to set the narrowness of your range depending on how actively you wanted to manage your LP positions. If you don’t want to watch it too often, then set your range wide enough to capture the bulk of price movement (and fees). If you’re the more of an active LP-er, then you can narrow your positions so that your liquidity earns more fees for less, but you have to move it an pay gas when the price has gotten out of your range.

There is so much more to this, but I guess this whole V3 thing has opened up a bunch of new possibilities in terms of innovation (comparatively) in traditional orderbooks and market making strategies on crypto, and it is a long topic so it will be for another post. I promise it’ll be less abstract and more visuals and stories from there!

Uniswap v4: Hooks and the Death of Routers

Just as I thought that it couldn’t get any wackier in V3, Uniswap announced its release of V4 drafts just a few days ago. And boy, it was so different. For one, the Router is gone. The pool factory is nil, too. Instead it has a singleton contract with just about 500 lines of code that holds all of the pools you could ever use in Uniswap 🤯🤯🤯 This saves gas big time, as you no longer have to pay double fees and gas even if your most efficient route takes more than single swaps.

If that’s not different enough, pools can now have their own rules, too. Pool creators can now use this thing called hooks, which are externally deployed contracts where you can write your custom logic and execute it at a specific point of trigger from the pool. When a trigger event happens, Uniswap’s hook contract calls back the specified hook of the pool creator.

This deadly combination of having a Singleton contract to hold all pools and having Hooks to create custom rules for each of them can have several use cases for the traders and liquidity providers:

-they can have oracles of all shapes and sizes, making it easier to create tools for both manual and algorithmic traders alike

-pools can have volatility-based fees

-LPs can automatically send their inactive liquidity somewhere else to make more $$$

-autocompounding of LP rewards

-redistributing internal MEV profits to the LPs

…These are just some suggested by Uniswap Labs themselves. There are definitely more. Danki haz a few ideas like active cross-pool liquidity management, but maybe and I’ll share more of these once I’m totally convinced of my POC.

Aliens next?

Geez. If you’re still here, then congratulations, you now have more knowledge of AMMs than most DeFi degens. I’d consider you a fren.

And since you’re frens with Danki now, I’ll tell you a secret: I expect V5 to be more boring than V3 and V4. Maybe a super cheap crosschain swap for later or some improvements in privacy. Though who knows, my brain iz too little to wrap around all the developments in the space and the new ways you could connect them together. But my bet is that we’re transitioning to a new meta after Uniswap has already solidified its most important features. The ground has already been laid for new financial products to thrive.

Or if that’s not it… maybe some AI or ML integration will reopen the Pandora’s box for DEXes, but I dunno how that will happen. I’d like to have you share some insights too! 🐴🌟

Consider these two scenarios: First is an eth economy where the value of the currency is high because a lot of it has been locked up by speculators looking for yield. The second is an economy where the value of eth is high because a lot of people have been using it to pay gas, burning it on transactions, and biggest of all, using it to supply liquidity in DeFi protocols. Which one is more sustainable?

I dunno bout you, but I’d go for the second- the demand-and-churn driven price. Merely inflating a token’s value by hoarding the supply doesn’t seem to be a healthy strategy for growing an ecosystem because at some point, stakers will be looking to sell.

You could be wondering what em blabbering about. I’ll tell you fren. But please don’t call da tokhang task force coz Danki is completely sober. I just stumbled on some really good shit. It’s called LSD-- short for Liquid Staking Derivatives.

Unfreezing Liquidity

The catch is that we need to stake to more validator nodes to secure the network and prevent centralization, but we also need that eth for liquidity in our DeFi markets. Well, there’s the demand.

The other dot to connect is that eth staking protocols issue their stakers a token that represents their staked eth. They needed it to keep track of who owns what amount of stake, and then they burn this token once the eth is ready to unstake. This token is by the way your LSD, and it functions like an IOU from your staking protocol.

The final dot in this trifecta of liquidity is that some dexes and exchanges started to offer ETH to stETH swaps… so you don’t even have to wait for your stake to unlock to get back your ETH .

Given this high level of liquidity, it didn’t take long for people and protocols to realize that they could as well use their staked ETH as a means of exchange… almost as good as real ETH, with gas usage the exception.

And so, the first domino falls…

There are many, many implications to LSDs, but the first thing that happened is that it just made that ~5% yield you get from staking your ETH totally risk free. It’s almost a no-brainer to stake now because you can just exchange your staked tokens back to ETH in any popular dex out there, at any time you wish.

And while danki iz (personally) not a pure believer of efficient markets, i know that risk-free transactions will be a magnet to eventually pull a really huge portion of ETH to be staked inside validator nodes.

Except that actually, it already happened.

The start of an LSD Summer

The biggest barrier to entry to staking is the 32 ETH minimum requirement to run a validator node. That’s a lot for your average cryptobro. So staking protocols like Lido offered to pool people’s ETH to run nodes. Now anyone can get staking yields for any amount of they wanna stake.

Of course people eat it up. And now Lido with its whopping $13.08B TVL (that’s approximately 26% of all value locked in DeFi application) became the biggest protocol in the face of the planet, in just a span of months. And my hypothesis is that it will still get bigger.

It gets crazier though.

At one point Lido’s dominance posed a threat to Ethereum’s decentralization because they operate a huge portion of validator nodes. They eventually shifted to delegating to other node operators, but the operators still need to apply to Lido, making it permissioned. This doesn’t sit well if you’re an advocate of decentralization wanting to stake to both earn yields and help the ecosystem at the same time.

So you’ve guessed it, new liquid staking protocols emerged. For instance, there’s RocketPool that runs a permissionless network of node operators and offers the same thing Lido does but with a more diverse set of validators and infrastructure.

Then there are some more protocols that were made for better UX and easy integration, but you get the gist.

Change of Meta

Der are two more things I wanna give as your takeaway about LSDs: first is that allowing for staked ETH to be spent like normal ETH opens up a whole new market for yield-bearing assets. And I wanna talk about fascinating new primitives that emerged because staked ETH.

Second is that since ETH is not merely a financial asset but also a way to secure the consensus layer of a network, liquid staking derivatives also opens up new possibilities and risks for other aspects of the ecosystem, and not just on the DeFi side.

But I’ll take a break for now. There’s also somewhere in DeFi that my hooves can’t just stop typing about. Those are… AMMs haha. I promise it’s going to be a full story next time tho 🐎✨

At the time it looks like I’m in the perfect spot to be a bridge. Em smart enough to build and fully understand what’s going on the cryptoverse but em also dumb enough to only talk about it using relatable human language.

And maybe dat is how I got you, my few handful of subscriber frends. That, or you enjoy seeing me make awkward metaphors about an obscure, super niche subject that my mom would never understand.

But here’s where being a bridge gets tricky: at one point, you’ll feel the gravity pulling you towards the world with the larger entropy. In one of those days, you start thinking “What if I stop half-assing these two worlds and commit to just one?”

That day is today.

I’ll tell you the story at the end of this post, but first let’s talk about cross-chain bridges.

Why do we even bridge?

Say you want to send some ETH as a gift to your crush who is a Solana moonboy. Surprisingly, he would gladly accept your ETH (and maybe your little hart as well) but there’s just a little problem: Solana is a different chain from Ethereum.

Now you might ask, “Why is there even a problem with sending ETH to Solana? Can’t we just send it to the other chain and transact in peace like god intended us to be?”

Well, sadly, the two networks are built differently. Their data structures, mechanisms, as well as programming languages are not the same. Imagine wanting to send a text message using telegram. You can’t no matter how destined you are.

Here’s another more realistic scenario because let’s be honest your crush doesn’t like you: what if you wanted to use your ETH as collateral to a loan to a DeFi protocol in Solana? How do you even do that?

Breaking down the problem

My dankibrain got very confused when bridges are explained to me. But then I realized it is confusing because it is a complex problem that needs to be broken down. So after hours of chewing and chewing information, I decided that there are three components to the cross-chain interoperability problem:

1. How the blockchains communicate their state

   Since the chains vary so much in their design, there is only one way they can communicate their state to each other, and that is through off-chain attestation. Meaning, you get an intermediate blockchain or a decentralized oracle network to tell the chain what is happening to the other. This is how LayerZero and other bridges that use Chainlink’s CCIP work.

2. How the tokens are ‘transferred’

   Lock and Mint aka. Asset Wrapping - the user locks their tokens inside a contract (or a node depending on the design of the network). An attester verifies that the user has locked their tokens and then mint a synthetic version of it in the destination network. When the user wishes to bridge back, they burn their synthetic token and get released their locked original tokens back.

   Omnichain Fungible Tokens - this is basically just lock-and-mint but instead of minting a chain-compatible synthetic asset, you deploy a locked proxy contract in the omnichain so that the tokens remain in their native form, and then you can mint it to a destination chain.

   Cross-chain Pools - This clever mechanism didn’t even require cross-chain communication. Just buy a stable asset of a protocol that has it in many chains, and then exchange that asset back in the destination chain that you wish. Voila.

3. How the bridge ensures that no tokens will be stolen

   This is probably the most heated topic when it comes to bridges but also the most no-brainer. You got two options when it comes to who manages your locked bridge tokens:

   Trusted/Custodial bridges- when your locked original tokens get managed by a central governing authority that verify and confirm your transaction and then mint a synthetic equivalent token that you can use on the other chain. The downside, of course, is that you have to trust them to not run away with your real tokens while you’re using their synthetic version. This was implemented in wBTC with BitGo as their institutional custodian.

   Trustless bridges- when your tokens get minted and burned algorithmically. Your tokens are locked in a smart contract until you have burned the synthetic token. There is no getting around the system.

   As in the case of Bitcoin, one example of a trustless bridge is Wanchain’s renBTC, where the token-holding nodes are cryptographically secured through Multiparty Computation. Participants only hold a component of the key to the locked tokens so that no single node can steal it.

A Game of Weakest Link

It’s always the bridges that get hacked in DeFi. At first, it’s unclear to my little dankibrain why, but then I put it like dis: Why do airports always have the tightest security?

Aha, because the entry of even just a single bad actor can terrorize the whole country. If your neighbors are sick, you get sick as well. If one of the chains are compromised, it can result in an imbalance of tokens for both. The attack surface just significantly got bigger.

And some of the biggest bridge hacks that I can remember aren’t even because of a bug. Bridge design is quite complex that sometimes, the architecture of the system is the bug. And then there is also that single smart contract that keeps all that valuable locked tokens, which is a pretty hot target for a lot of mallories.

Anyway, that’s enough caution to using bridges for you. Just use native tokens if you can. And may the odds be ever in our favor.

******

I had two brushes with the larger blockchain world this week.

First is dat I met a frend who is hellbent on spreading a blockchain movement in the country. He is a very well-connected guy but he wanted to start developing in this small city in the mountains.

I can see his idea though. He got jaded in the mainstream web3 culture in the big city where people seldom talk about real world use cases of decentralized tech. So he’s starting here where the population is young and passionate and highly educated. A clean slate. We are on the same cause.

Two days later, I met my mentor. For some cosmic anomaly this guy who is already deeply entangled in the global DeFi scene found Danki on the webz while he was takin a vacation in his hometown. And his hometown, of all places, happens to be this sleepy town where I live.

Dankibrain haz never expanded so much as the few hours he haz talked about DeFi. And I have never thought so hard about where I wanna go after that conversation. Which leads me to my point…

I’d stop being your bridge and start tying you to my waist so I can pull you to the other world. And I might talk more freely in this blog 😅 I’d probably write about some alien topics dat I’m scared no one will read.

Or yeah, the goal anyway iz to tap dance alone so it doesn’t really matter if anyone is reading dis. But I hope you still hang around in dis little rabbit hole. DeFi is a big place, I’d tell mor shiny moon math soon. 🐴✨

Anyway from dis point on we’ll probably have less Marites and more cryptography, because I want my frens to know wat these things are called in the actual ZK world. So lezgow.

Fiat-Shamir Transformation in Detail

As I sed, ZK-SNARKs make use of a trusted setup as their verifier. And that a trusted setup is an algorithm that looks like dis:

Now, there are two things you can note about this:

First is that the trusted setup uses a randomizer at #2, when Peggy picks a number to evaluate from.

The second is that in #3 Peggy runs her answers through a hash function… and a hash is a one-way function where you can compute for the answer but you cannot derive the variables that were used to get your answer. So at this point, there’s no way Peggy could have guessed the result of her hash beforehand, not until she runs her variables in the trusted setup.

This two-part mechanism ensures that the prover could not fake their proofs.

At #4, Peggy just creates the proof by evaluating her hash through another function and submitting this value along with the number she has computed in #2. This proof is publicized and can now be checked by anyone by plugging these values to the equation in #5.

And that, my frens, is how ZK-SNARK works.

Polynomial Commitment

Remember why Becky couldn’t just recite the polynomial to Marites in the previous article?

Becky as the prover can’t just give away the polynomial because it practically gives away her 10 million gossips to Marites who may or may not be trying to fish for it. Plus the polynomial is just too lengthy to recite.

So instead of doing that, we use a commitment scheme called the Polynomial commitment scheme.

Wat agen? Okay let’s dissect dis frens…

A commitment scheme allows you to commit a value while keeping it hidden, like putting a note inside a vault. In our analogy, Becky could put her polynomial inside the vault to solve this problem. Now she sends the vault to Marites.

There’s still a problem with that tho. Marites doesn’t have the key to the vault, and Becky isn’t willing to give the key because that would be giving away her precious polynomial to a stranger she doesn’t trust.

So what does Becky do? She constructs a special kind of vault that can prove to Marites the value of her polynomial at whichever point Marites asks to evaluate. And dat special type of vault is wat we call a Polynomial Commitment, or PC.

Now for the magic trick…

Merkle Trees, the data structure through which blockchain data are stored, has properties that act like a polynomial commitment scheme.

As you see, each node contains a hash of the child nodes below them. So the top hash, or the merkle root, is a hash you can only arrive to if you compute all the hashes from the nodes below it. The top hash represents and proves the existence of all the data below it without revealing what they are.

Can you see the similarities now?

What if we do this then… Let’s store each term (the variables and coefficients) of Becky’s polynomial inside a merkle tree node. Then we hash them to arrive at a merkle root. Now this top hash serves as a polynomial commitment without revealing any part of Becky’s polynomial, innit?

Now you know how it all fits together in ZK-SNARKs.

Wait, ders more…

Gomsh it’s been a long ride, and by now I hope you already have an idea of how the parts work to produce a ZK Proof. We used ZK-SNARK in our example but as I sed, there are many, many flavors of ZK. And there are many kinds of commitment schemes.

For instance, let’s see a polynomial commitment scheme called FRI, which doesn’t even need a trusted setup and is being used by the other common type of ZK, ZK-STARKs.

Fast-Reed Solomon Interactive-Oracle Proofs of Proximity (I can’t pronounce it, so just say FRI)

Ders a little problem in checking the polynomial commitment in order to verify a polynomial. First, how does the verifier tell if the commitment even represents an actual polynomial? And second and more commonly, how do we check if the polynomial is not so enormously sized that it’s impossible to use for computation?

Dis is where we use FRIs.

The idea with FRI is that we check the degree of the terms inside the polynomial by running them through a certain mathematical transform (commitment phase) and then letting the verifier evaluate how a few points in the diagonal fits within the range of a graph derived from a billion data points (querying phase).

There are still ways to make the FRI more efficient for both the prover and the verifier which you can read on Vitalik’s post.

There ar also many other polynomial commitment schemes that are widely used in the blockchain space, like the KZG commitment that will be used in Ethereum along with Proto-Danksharding. But I’ll reserve that for a different post later coz boy, what a story already.

Anyway, I hope dis has fed your ZK curiosity for today. Maybe on the next post we’ll talk about the application side and how ZK circuits are actually created. For now, hold Danki’s promise dat der will be another ZK post. Byebye!

If you have no idea what this is all about and why danki is so happy as my hooves type dis post, then check out Part I.

But if you’re too lazy to click… ZKP or Zero Knowledge Proofs is a cryptographic mechanism that allows you to prove that something is true without revealing any more information other than the fact that it is true.

It sounds like magic, so today I’ll demystify how this happens under the hood.

Consider this problem…

Let’s say Marites has ten million data points of hot gossip (it’s a really huge set) and told it to a person inside a confession box. That person is Becky, but Marites doesn’t know that.

How does Marites ensure that Becky is the person who heard all her 10 million hot gossips?

Well, der are a few ways that Marites can verify from Becky:

Option 1: Ask Becky to recite all the 10 million gossips

Now, this frens, requires a martyr out of Marites and Becky. Because who has time to recite ten-facken-million gossips? It requires so much time and computational power from both of them that it’s impractical.

Option 2: Ask Becky to just recite one gossip from the set

Fast, but it doesn’t prove that Becky really has all of the gossips. Becky might just have a lucky guess.

Option 3: Make a polynomial whose graph go through all the 10 million numbers that represent each gossip

Holy schmoly. This is probably the answer, but you’re now thinkin, “whuuut--?”

Okay, calm down. Just look at this:

Notice that any two different polynomials go through different points most of the time. There may be a few points where their curves intersect, but that’s about it.

Now, let’s say dat this is the polynomial that goes through Marites’ 10 million gossips. Of course just imagine the real one will be much, much complicated but for da sake of visualization:

If Becky knows the 10 million gossips, she can recreate this polynomial.

But the polynomial will be complex and it is still too lengthy to recite to Marites… Besides, from Becky’s point of view, she doesn’t know if Marites is a actually the person who told her the 10 million gossips while she’s inside the confession box. If she gives Marites the full polynomial, she practically risks leaking all the gossips to some random stranger.

So Marites, instead of asking Becky for the polynomial, will give Becky a number and ask her to compute for the value of the polynomial at that number. If Becky answers correctly, then Marites is convinced that Becky knows the polynomial and is really the person who heard all her 10 million gossips.

And voila, that is ZK Maths in a nutshell my frens.

Non-interactive ZK Proofs

What if there are many people claiming to be Becky? Marites will soon find that it’s tiring to pick a number and it’s taking so much of her energy to ask the same cursed question everytime.

So everyone agrees to just evaluate the polynomial at x = 123.

Cool. Now Marites doesn’t even need to ask the question. Anyone who claims to be Becky can just post their answer and a robotic verifier can check.

But there’s a problem with this. If everyone has the power to set the question and they already know the question beforehand, it will be easier for someone to cheat on the exam innit?

Presenting ZK Snarks-- dis neat little non interactive ZK creates a trusted setup for picking the number. In the trusted setup, no one knows the number beforehand because it will be generated as the verifier interacts with the setup.

If you’re curious what this trusted setup is, it’s just an algorithm. And the algorithm is created randomly in a trusted setup ceremony.

Anyway, an example of a trusted setup works like this:

This math or mechanism where the prover uses a trusted setup to create a digital signature from their proof is called the Fiat-Shamir Transformation.

Ok, dis has gotten longer than I thought

Somry fren, but we have to continue dis some other time. Danki iz hungry now, and the next one will be about ways a ZK-SNARK improves all these polynomial verifying via polynomial commitment and recursion, which iz a topic of its own.

So wait for it. Mor mor math once Danki haz been fed.

つづく

The idea iz already yummy as a sundae on our 35°C sweltering weather, but the cherry on top is better: we three are all writing for you, frens. Three columns from three people with different and reliable expertise, all in one publication. Danki can’t contain it, I hab to tap dance 100x faster 🐴✨

The thing is, there aren’t many resources about Decentralized Finance that cater to Filipinos and their unique context. We fell inlove with NFT Art and GameFi, and y’all aped into memecoins… maybe it’s time to level up to something that is less abstract and closer to utility? Because beneath all the NFT craze, P2E, and hot new tokens-- beyond all the hype, rugs, and schemes… there is an underlying capital markets dat is developing and it’s time that you know about it, too.

And no, Danki iz not talking about shiny new things to hype. Please don’t turn DeFi into another marketing scam or I’d be first to kick you. Em talking about actually understanding blockchain technology, getting a detailed perspective on how it works, witnessing firsthand its application in finance and many other things. We’re talking research. We’re talking analysis that iz not fed to you like junkfood to the brain, but something you can do on your own.

Because we believe in our readers’ intelligence. And so we are making a channel that allows you enough understanding to make your own sober judgements of blockchain protocols and their implications.

And of course, more memes.

See you around!

Well, not really. I was reading codebases everyday and practically lost track of the days. And the further I went, the harder it was to explain what the hekk iz Danki up to. I was already deep into Curve’s Stableswap Equation when I realized that almost a week has already passed.

So here I am frens, doing my best attempt to catch you up.

Now the story. It all started with Constant Product Market Makers…

The Most Basic Type of Swap

If you’re swapping your USDT for ETH on say, Uniswap v1, then USDT doesn’t magically transform into ETH tokens through some wizard program. No na no… instead da ETH is already stored somewhere, as well as the USDT you just deposited. And that ‘somewhere’ is called a liquidity pool.

In the USDT-ETH example, a liquidity pool works like this:

1. Somebody initially supplies two tokens in the pool, in equal value

2. As users like you start swapping their tokens in the pool, the ratio of the two tokens change

3. But the total liquidity remains the same, just the ratio is different

4. The price of one token is computed by the ratio of its supply with the other token.

…And this liquidity is expressed in the famous Constant Product MM equation:

x * y = k

Where x is the amount of token1, y is the amount of token2, and k is the liquidity of the pool.

So the price of each token changes as people swap because the ratio in the liquidity pool changes.

It looks like dis…

Say, somebody initially supplied 10,000 USDT and and 5 ETH in the pool:

At this point, if we use x y = k, then k = 10,000 * 5 (which is 50,000). And the ratio will be 2,000 USDT per 1 ETH

Now, enter you, and you wanna swap your 2000 USDT for ETH. Let’s ignore fees for now. How will this affect the pool and at what price will you get your ETH?

Well, you are practically adding 2000 USDT in the pool which should correspond to a change in the amount of ETH. ETH will decrease in order for k to stay constant.

Then, the market maker will solve for the amount of ETH it will give you:

k = 50,000 = (10,000 + 2,000) * (5 + dx)

dx = -0.833333 ETH

ETH supply in the pool will decreased by 0.833333, which is the amount they’ll give you for the 2000 USDT you deposited

“But why 0.8333333, I thought the price is at 2000 USDT per 1 ETH!”

Were you cheated? Not really, because the ratio of USDT per ETH was going up as you were adding more USDT to the pool, bringing the price of ETH higher than what was initially shown… And dat, frends, is called the price impact of your trade.

And because price is computed by the two token’s ratio in the pool, the lower the k value or liquidity, the bigger the price impact of each swap.

In traditional finance, you can also recognize the same phenomenon where the low-volume assets are more volatile. In their case, instead of an algorithm, the market makers are the hedge funds (except the hedgies got alpha but that’s for another story lol).

Anyway, the amount of tokens in the pool is not only affected by swaps. Liquidity in the pool can also be removed or added.

Then what happens if somebody provides more liquidity?

When somebody provides liquidity to a protocol, they get minted what is called an LP Token. The LP token represents the percentage of liquidity that the user owns in the pool. This keeps track of how much of the pool they can withdraw and the share of rewards they get from the collected fees.

Ok, let’s see this in action.

Say, your good frend Marites supplied 5 more ETH and 10,000 USDT to the pool at the current rate of 2000 USDT per 1 ETH.

The pool had 5 ETH and 10,000 USDT before and had minted 10 LP tokens to its providers, and now that Marites added to it, it has 10 ETH and 20,000 USDT. Rich frend Marites now owns 50% of the pool, and she gets minted 10 LP tokens for that. Now she owns 10 out of the 20 LP tokens.

If Marites wanted to withdraw her share of the pool, she will burn the 10 LP tokens.

But will Marites get the exact same 5 ETH and 10,000 USDT she deposited?

99% of the time, she will not. Instead she will get her two tokens in whatever ratio the pool currently has after users have swapped tokens in it. This could result to impermanent loss.

I wanna talk about impermanent loss, but das a long topic that I reserve for investors, traders, and degens in DeFi Philippines. If you wanna know more about the benefits and risks of providing liquidity to a Constant Product AMM, wait for my post in there!

You will rarely find pure CPMMs nowadays

It might sound amazing on paper, but the reality iz Constant Product MMs are very inefficient in managing liquidity.

Most of the liquidity in the pool will fall on the extreme ends of the curve where they aren’t utilized. Meanwhile, price impact is still huge in the middle range where most of the trades happen. So the newer dexes and protocols use a different model to remedy this inefficiency… and that’s what I actually wanna talk about. haha

But at least now you understand how the most basic form of AMM works, and we can move on to the real exciting part. We’re gonna talk modern market maker models in the next posts! 🐎✨