Workshop 2 with @HardhatChad & @ORE: meaningful ORE integrations to be eligible for the bonus prize. —————————————————— KEY TAKEAWAYS —————————————————— 1) Build around a useful ORE experience. The central distinction is between simply supporting a token and making ORE part of a product's user-facing purpose. A generic balance, transfer or swap interface is a weak demonstration of integration. Mining, data, staking, liquidity and more inventive mechanisms offer a wider design space. 2) ORE's mining protocol's rules do not dictate the app's appearance. A mining client interacts with the on-chain program, but its UI need not reproduce the familiar 5×5 grid. The host proposes a game character mining rocks; Chad confirms alternative interfaces are possible. 3) Automation is a product responsibility as well as a ORE smart contract feature. The deploy instruction handles SOL deployment, while automate creates an account containing the user's rules or delegated strategy permissions. Automation can be cranked permissionlessly or restricted to an operator. Restricting it gives the operator responsibility to keep it running; otherwise the user-facing app stops doing its job. 4) Good data products can be useful without moving user funds. Opportunities include miner performance histories, supply/emission views and liquidity information. Chad describes missing data users ask for and ways to repackage existing analytics. A read-only product and a transaction client are distinct valid product directions; award eligibility still depends on the event's actual terms. 5) Know which repository supplies which function. The core ORE program, staking program, liquid-staking wrapper and starter frontend are separate pieces. A combined mining-to-staking flow might use more than one. The standalone ORE CLI repository discussed later is an experimental smart-wallet project, not simply a mining command-line client. 6) Rust contracts do not force an Expo app to be written in Rust. Chad says the team did not have an Expo/React Native starter. He recommends generating client code from the program's IDL and reviewing its account/instruction documentation. The existing starter uses Rust and Dioxus; it is a reference, not a ready-made Expo project. 7) Explore real friction before choosing a feature. Mining pools can reduce each participant's share of transaction fees by combining activity. Liquidity management and missing mining data are other concrete problems discussed. Novelty can also come from a better workflow for an existing mechanism, not only an entirely new contract. 8) Separate available tools from brainstormed financial products. Lending against unrefined rewards, ORE-backed coins, redirected yield and a friendly smart-wallet frontend are ideas explored in the conversation. 9) Only one top eligible ORE-integrated winner receives the match, chosen by the ORE team; the integration must be live and visible in the submitted app. Payment is described as staged/milestone-based, with continued work expected. 10) Chad says the team does not intend to build leverage products internally and can help outside builders think through them. He also says privacy improvements are underway, so privacy builders could overlap with future in-house releases. Cross-chain reserves are discussed as an open idea that he may be excited to see. 12) Talk to the ecosystem and test actual behavior. Chad points developers to the ORE Discord dev channel and a builder role/private support space after showing real progress. There is no devnet deployment available for ORE; he explains why the team tests on mainnet. ————————————————— ORE AND PRODUCT OPPORTUNITIES ————————————————— 1) What is ORE trying to be? Chad describes a Solana-native, Bitcoin-like store-of-value asset intended to work with Solana DeFi without needing a bridged asset. He names mining, staking, reserves and shield pools as parts of the ecosystem. 2) What are the main integration points? Mining clients, data/analytics products, staking experiences, and liquidity/reserve-related tools. Chad emphasizes demand for better mining clients and missing information. Liquidity management is a potential area with rough user experience. 3) Can a useful integration be read-only? Yes, as a product direction: Chad discusses sites that summarize miner history, supply, emissions and market data without deploying SOL. 4) Must a mining app show the usual grid? No. The grid is a common frontend convention, not the only possible interface. There is room for a different presentation, including the host's game-like example. 5) How does an alternative frontend actually interact with mining? It reads accounts and sends transactions to the ORE mining program. The program contains the round, grid, minting and other protocol rules. The frontend changes the user experience while the program continues to enforce the underlying behavior. 6) What is the difference between deploy and automate? deploy handles a user's SOL deployment into the mining grid. automate creates an on-chain automation account containing deployment rules and permissions. A user can choose their own rules or delegate strategy decisions to the app operator. 7) Can I run a strategy for users and collect cranking fees? The interview describes that possibility through automation permissions. A permissionless crank lets outside bots participate. A restricted crank can limit execution to the operator, but then that operator must reliably execute it. The discussion does not promise strategy performance or profitable fees. —————————————————— REPOSITORIES, SDKS AND EXISTING EXAMPLES —————————————————— 8) Which repository should I begin with? Use the core ORE repository to understand mining accounts and instructions. The starter app is a stripped-down version of the main frontend with mining and wallet connection. Use the staking or liquid-staking programs when those are the functions your app needs. 9) Can I build a different staking frontend or combine mining and staking? Yes. Chad describes alternative staking UIs and a flow that claims mining rewards into a staking-related product. The ORE staking program manages stake accounts and yield distribution; the LST program wraps that functionality into a staking token. The exact combination depends on the intended workflow. 10) Is there an Expo/React Native starter? No, not for ORE. The recommendation is to use the IDL and generated documentation to build a JavaScript/TypeScript client integration. The team uses Rust across contracts, backend and its Dioxus frontend. 11) What would Chad most like builders to make? Something useful and surprising. Competitive mining clients are welcome, but the team is especially interested in ideas they have not already conceptualized. This is an invitation to explore, not a fixed checklist of winning categories. 12) Is there already an ORE app on Seeker? Chad describes the main app as a web/PWA-based experience packaged for Android, plus community mining clients he believes are available in the store. He explicitly qualifies some third-party availability from memory. 14) What is the standalone ORE CLI repository for? An experimental smart wallet using a two-of-two arrangement: a regular Solana key and a Falcon-512 post-quantum key. The CLI creates and operates the wallet and supports ORE staking. Chad identifies a friendlier frontend as an interesting project, while stressing that it would effectively be building a wallet. 15) What existing community products are worth studying? Chad mentions Ruby's pool-mining product and ORE Stack as examples, with uncertainty about exact current store listings and URLs. Pools combine users' mining activity so they share transaction-fee costs. The interview also names data sites earlier; it does not verify their present availability. LENDING, NFTS AND OTHER DEEPER INTEGRATIONS 16) What makes an integration meaningful beyond token payments? @KEMOS4BE argues for uses that reinforce ORE's intended store-of-value role and put it behind another useful product. Chad builds on that with redirected yield and other mechanisms. The main test is whether the integration changes what users can usefully do, rather than merely adding a ticker to an existing interface. 17) Could someone lend against unrefined ORE? Chad describes a prior builder's idea for lending SOL against unrefined rewards, with the lender funding the loans and able to claim collateral after default. He does not know that the product launched. He explicitly identifies leverage as high risk; the discussion is a design exploration, not an available lending offer. 18) How could a lending app control that collateral? The mining account has an authority controlling the tracked rewards. Chad sketches a proxy program whose PDA becomes the miner-account authority and calls into ORE, so the lending program can control/claim the collateral. A frontend alone would not supply that enforcement. Risk controls and a full lending implementation are not worked out here. 19) Can users already borrow against ORE? The speakers discuss a past listing that is no longer available and prospective conversations with another protocol. They do not confirm a live current borrowing venue. No specific new listing was confirmed. 20) Are prediction markets or leverage products a direction the team wants? Chad has no ready prediction-market proposal. For leverage, he points back to lending against unrefined rewards and says the team expects outside partners to build those products rather than doing leverage internally. The team can help discuss the design. 21) What other speculative ideas were raised? A focused discovery/creation interface for ORE-related meme coins, and a wrapper that redirects staking yield to one or more wallets, potentially after converting it to USDC. These are brainstorming examples, with demand, economics and implementation left open. TESTING, PRIZE RULES AND SUPPORT 22) Is there an ORE devnet deployment? Chad says no at that time. He would need to investigate deploying the collection of ecosystem programs there. He explains the team's preference for mainnet testing because network latency and RPC behavior can differ from devnet. No devnet release date is promised. 23) Where can developers get technical help? The ORE Discord dev channel. Chad describes a builder role and a more focused ecosystem support chat for people showing a working product/progress, including topics such as RPC costs and technical best practices. KEMOS4BE also offers design feedback and help routing technical questions. 24) Does every top-five project with ORE receive a prize match? The later term-sheet discussion says only one top eligible ORE-integrated winner gets the match, determined by the ORE team. This is more specific than the earlier loose description. Do not turn the earlier remarks into a promise that all top-five teams receive doubled prizes. 25) What did the qualification discussion require? A user-facing integration live in the submitted project, rather than hidden unused code; ORE being the primary featured/promoted product where competing products are supported; continued availability of the integration; progress updates; and milestone-based payment. General hackathon payment is also described as requiring dApp Store publication, even if an app can be submitted before listing. The written agreement remains the source for exact obligations. 26) Is payment in USDC or ORE, and when is it paid? Chad says he had assumed USDC and is open to ORE if builders prefer. He describes vesting/staged payments to support continued development, but does not state a firm duration. Currency flexibility is a conversation statement, not a finalized award commitment. PRIVACY, CROSS-CHAIN AND PAYMENTS 27) What privacy integrations exist? Chad describes Privacy Cash shield pools for ORE and the staking token, with a minimal interface on the main site. He also says privacy updates are underway and cannot promise that a new third-party privacy product will avoid overlap with an in-house release. The recording does not define or verify exact privacy guarantees. 28) Would cross-chain ORE products be interesting? Potentially. Chad discusses reserves or liquidity on another chain as one way to think about durability beyond reliance on Solana. He leaves the product shape and bridge work to builders. No specific cross-chain launch is announced. 29) Do ORE payments qualify as an integration? It depends on the actual product. Chad mentions an existing payments integration, but says it has not generated much volume, partly because holders prefer to keep ORE. Credit backed by ORE is raised as a potentially more aligned idea; it is not confirmed as shipped or automatically prize-eligible. 30) Could staking yield be paid out in USDC instead of compounding the token? The host proposes redirecting and converting yield into a wallet or a fan-out of wallets, using a different wrapper rather than the normal accumulating staking token. It is discussed as a product possibility. The tax treatment was not established in the session; converting yield to USDC should not be treated as automatically eliminating tax consequences. ————————————— MORE FAQs FOR BUILDERS ————————————— What is the clearest beginner integration path? Pick one mechanism: a mining flow using the core program, a focused staking experience, or a useful read-only dashboard. Use the matching repository and IDL instead of treating the whole ecosystem as one API. Prize qualification depends on the event’s written terms. Does my app need its own smart contract? An ordinary client can interact with existing ORE instructions. A more involved product such as collateralized lending may need a proxy program with enforceable control of miner accounts. The answer depends on the mechanism you are adding. If I draw a game over mining, is it automatically a meaningful integration? No automatic qualification is offered. Alternative UIs are encouraged, but the later discussion requires an actual user-facing integration. The gameplay should represent a real useful interaction, and the ORE team determines match eligibility. What should I demonstrate to make the integration easy to assess? Show the user-visible ORE flow actually working in the submitted app, and explain why that mechanism improves the experience. Hidden code and a generic token toggle are weak evidence. Can I assume a pool or automation strategy guarantees lower total costs or profit? No. The interview explains fee-sharing and automation mechanics. It does not provide audited cost comparisons, return forecasts or guarantees. Can a wallet frontend simply inherit the prototype's security claims? No security audit is supplied in the session. Chad calls the CLI experimental and explains its two-key design. Turning it into a consumer wallet carries more responsibility than copying a UI. Will the ORE team compete with my product? The conversation distinguishes categories: Chad says leverage is expected to come through partners, while privacy features are actively being developed internally. It is not a blanket promise about every product category. What remains unanswered before building a lending or redeemable-NFT product? For lending: collateral control, valuation, liquidation and risk limits beyond the proxy sketch. For NFTs: what quantity/asset redemption returns, how yield is separated and what holder utilities actually exist. The recording supplies concepts, not complete specifications. How does the mainnet-testing advice fit with Beeman's devnet tutorial? They address different contexts. Beeman teaches a generic mobile/wallet development workflow on test networks. Chad says the ORE ecosystem had no devnet deployment and describes his team's mainnet testing practice. One does not invalidate the other. What should be checked before turning this into public prize guidance? The official match eligibility, number of recipients, amounts, payment currency, milestones/vesting and publication obligations. The recording contains tentative early explanations followed by more specific later terms; use the written agreement for definitive guidance. —————————— INTEGRATION IDEAS —————————— MINING CLIENT WITH A DIFFERENT UI Covered in the session: Existing program and instructions; alternate frontends are possible. Still open: Product fit, implementation quality and match eligibility. MINING/DATA DASHBOARD Covered in the session: Described as a common ecosystem product with missing-data opportunities. Still open: Exact data sources, indexing costs and event qualification. POOL MINING Covered in the session: Existing community example; sharing activity can reduce each user's fee share. Still open: Pool design, costs, reliability and actual economics. STAKING OR MINING-TO-STAKING FLOW Covered in the session: Separate existing programs can be composed. Still open: Best user flow and client integration. LIQUIDITY MANAGEMENT Covered in the session: Identified UX pain and partial visualization work. Still open: A complete management product and demonstrated demand. SMART-WALLET FRONTEND Covered in the session: Experimental CLI and two-key design described. Still open: Consumer readiness, security review and mobile UX. LOANS AGAINST UNREFINED REWARDS Covered in the session: Prior idea and proxy-authority sketch. Still open: Full risk model, enforceability and whether a product launches. ORE-BACKED ASSETS Covered in the session: Proposed backing/redemption and yield separation. Still open: Denomination, redemption terms and delivered utility. PRIVACY INTERFACE Covered in the session: Existing shield-pool proof of concept described. Still open: Exact guarantees and overlap with planned team updates. CROSS-CHAIN RESERVES/LIQUIDITY Covered in the session: Open brainstorming direction. Still open: Product, bridges, implementation and launch commitment. PAYMENTS/REDIRECTED YIELD Covered in the session: Existing payments anecdote plus new wrapper ideas. Still open: Demand, financial design and any claimed tax treatment.