From a stock holding to an on-chain lending flow
The hackathon explored how stock holdings could be represented as tokens and used in a lending application. My contribution was the application integration: connecting the frontend, backend, wallet and existing smart contracts into a testnet prototype. The project received an Honorable Prize.
The design used sandbox brokerage accounts and simulated asset data. Real stock custody, reservation and redemption were proposed extensions, not delivered integrations.
What I integrated
- Wallet and account state: connected browser wallets through Ethers.js, handled account and network changes, and connected sandbox account registration to application records in MongoDB.
- Identity and token issuance: connected server actions to an ERC-3643 / OnchainID client for identity registration, claims and registry checks. The minting workflow checked application prerequisites and recorded transaction hashes and tokenization records.
- Lending interactions: integrated collateral supply, stablecoin supply, borrowing, repayment and collateral withdrawal with the project’s lending contracts. The interface displayed balances, debt, borrowing capacity and position health.
- Transaction feedback: handled token allowances and approval transactions where needed. Lending actions waited for transaction confirmation before refreshing the displayed position, with loading and error feedback for the user.
The identity, token and lending contracts were implemented by other developers. I worked on their application-facing integration, not the underlying protocol logic. The lending component was a project-specific, Compound-style experiment—not an integration with a public Compound III market.
One interface, several kinds of state
The main engineering lesson was that wallet connection, application records and on-chain execution are different states. Connecting a wallet is not the same as completing an identity check; receiving a transaction hash is not the same as confirming execution.
Keeping contract clients separate from application actions helped make those boundaries explicit. In the lending interface, the sequence was allowance check, approval when needed, transaction submission, confirmation and position refresh. That sequence made the user’s next action easier to understand.
Related research and references
RWA Creator: connecting tokens to off-chain assets
My RWA Creator learning exercise references Patrick Collins’s original example. The focus was understanding two models rather than designing a new token standard:
- Asset-backed tokens: supported by holdings of the underlying asset off-chain, requiring a clear relationship between reported holdings, issuance and redemption arrangements.
- Synthetic assets: use other collateral and price data to create exposure without representing ownership of the stock. Price tracking and collateral management are separate concerns.
Oracles: request, response, then an on-chain update
The Chainlink Functions flow I studied was: contract request → off-chain API query → oracle response → contract processes the result. It was not one synchronous database transaction; the application needed to represent the waiting stage. Chainlink documentation
My takeaway was to distinguish price references, reported holdings and asset restrictions. An API response does not itself lock shares, and a redemption request does not mean funds have arrived. These were design considerations from the research, not a claim that the lending prototype implemented brokerage settlement.
This describes the original study. Chainlink now marks Functions as deprecated and directs developers to CRE; a new implementation would need to follow current guidance.
BUIDL: fund shares and an exit route
Circle’s published BUIDL facility lets holders transfer fund shares to Circle in exchange for USDC. That is different from assuming that burning a token automatically sells the underlying assets. My takeaway was to distinguish token operations, fund redemption and delivery of funds. BUIDL was an external research example, not one of my integrations. Circle’s original announcement
Scope
This was a hackathon testnet PoC, not a production financial service or a system handling customer funds. Sandbox account responses and token issuance did not establish real stock ownership or custody. The research notes and learning exercise above are presented separately from the application integration delivered in this project.