Detailed Instructions

Begin by tracing the complete asset lifecycle from origination to redemption. For a tokenized treasury bill, this includes the off-chain purchase by the sponsor, the creation of the legal claim, the minting of the representative token (e.g., an ERC-20), its distribution to users, and the eventual redemption upon maturity. Critically examine the on-chain representation. Is the token a direct claim on the asset, a share in a fund, or a debt position? Review the smart contract's role: does it merely track ownership, or does it manage cash flows and enforce rights?

• Sub-step 1: Document the off-chain legal structure and custody chain for the underlying asset.
• Sub-step 2: Analyze the token's smart contract to determine its mint/burn authority and pause functions.
• Sub-step 3: Verify the oracle or attestation mechanism that links the on-chain token state to off-chain reality.

solidityCopy
// Example: Checking minting authority in a common RWA token contract
function mint(address to, uint256 amount) external {
    require(hasRole(MINTER_ROLE, msg.sender), "Caller is not a minter");
    _mint(to, amount);
}

Tip: Focus on the points where data or control moves between off-chain and on-chain systems, as these are primary risk vectors.

Detailed Instructions

Assess the legal enforceability of the token holder's claim. For a real estate token, does it represent a fractionalized beneficial interest in an LLC that holds the title, and is this structure recognized in the property's jurisdiction? Identify all critical counterparties: the asset originator, the custodian, the legal sponsor, and any servicers. Evaluate their financial health, regulatory standing, and operational history. Scrutinize the legal agreements (e.g., Purchase Agreements, Custody Agreements) for clauses on default, insolvency, and dispute resolution. Determine the protocol's recourse if a custodian fails.

• Sub-step 1: Identify the jurisdiction governing the asset and the legal wrapper (SPV, Trust).
• Sub-step 2: Review publicly available audits or financials of key service providers.
• Sub-step 3: Map the flow of funds and identify which entity holds ultimate discretion over asset sales or transfers.

Tip: The strength of the legal structure often outweighs the smart contract code in determining ultimate recovery value.

Detailed Instructions

Oracles are the most critical technical component for RWAs. You must evaluate the data source, update frequency, and decentralization of the attestation mechanism. For a revenue-sharing agreement token, how are off-chain revenue figures verified and posted on-chain? Is it a single API call from the sponsor, a multi-signed attestation from a committee, or a decentralized oracle network? Check for circuit breakers or staleness thresholds that halt operations if data is outdated. Analyze the economic security and slashing conditions for oracle operators.

• Sub-step 1: Locate the updatePrice or submitAttestation function and review its access controls.
• Sub-step 2: Determine the time delay (e.g., 24 hours) between a real-world event and its on-chain reflection.
• Sub-step 3: Test the protocol's behavior by simulating an oracle failure or providing stale data.

javascriptCopy
// Example: A simple check for oracle staleness in a valuation function
function getAssetValue() public view returns (uint256) {
    require(block.timestamp - lastUpdateTimestamp < STALE_PERIOD, "Oracle data stale");
    return currentReportedValue;
}

Tip: A single, permissioned oracle signer represents a central point of failure that can freeze or corrupt the entire protocol state.

Detailed Instructions

RWAs often have limited liquidity and asynchronous redemption periods. Model scenarios like a mass redemption event (a "bank run") where token holders request to redeem more value than the protocol's liquid reserves. Evaluate the liquidity mismatch: if tokens are traded 24/7 but the underlying asset can only be sold quarterly, how does the protocol manage interim withdrawals? Analyze the fee structure and its impact on yields during periods of low asset performance. Stress test the collateralization ratios for debt-based RWAs (like asset-backed loans) against a sharp decline in the underlying asset's market value.

• Sub-step 1: Calculate the protocol's withdrawal queue capacity and minimum notice period for redemptions.
• Sub-step 2: Model token price deviation from Net Asset Value (NAV) under high sell pressure.
• Sub-step 3: Assess the stability of yield sources and the impact of sponsor default on cash flows.

Tip: The promised APY is less important than the durability of that yield through a credit cycle and the protocol's ability to meet redemption requests without a fire sale.

Detailed Instructions

Determine who holds administrative keys or governance votes that can alter core parameters. Can a multi-sig council unilaterally change the fee structure, add new asset types, or upgrade the token contract? If the protocol uses a DAO, analyze the proposal threshold, voting duration, and timelock delays. A critical review point is the ability to pause minting, burning, or transfers—this is a centralization risk that can lock user funds. Examine the upgrade mechanism for the core contracts: is it a transparent, time-locked proxy, or an immediate upgrade by a single entity?

• Sub-step 1: List all privileged roles (DEFAULT_ADMIN_ROLE, PAUSER_ROLE) and their current holders.
• Sub-step 2: Verify the duration of any timelock (e.g., 48 hours) on executable governance proposals.
• Sub-step 3: Review historical governance proposals to assess the concentration of voting power.

solidityCopy
// Example: Checking for a central pauser role in a token contract
function pause() external {
    require(hasRole(PAUSER_ROLE, msg.sender), "Must have pauser role");
    _pause();
}

Tip: Overly broad governance powers can negate the trustlessness of the smart contracts, reintroducing counterparty risk.