diff --git a/README.md b/README.md index f88783e..9e89f0d 100644 --- a/README.md +++ b/README.md @@ -30,6 +30,7 @@ Prizes are graded on a functionality gate **plus** adoption criteria (real third | File | Description | Size | Status | |------|-------------|------|--------| | [LP-0000](prizes/LP-0000.md) | Template — use this as the starting point for new prizes | — | — | +| [LP-0001](prizes/LP-0001.md) | NFT Wallet Support and Private Ownership Proof | Medium | Draft | | [LP-0018](prizes/LP-0018.md) | OpenStreetMap integration: decentralized map data distribution | Medium | Open | | [LP-0021](prizes/LP-0021.md) | LEZ Wallet and Provider SDK | X-Large | Draft | | [LP-0022](prizes/LP-0022.md) | Combined Blockchain and Zone Wallet | Large | Draft | diff --git a/prizes/LP-0001.md b/prizes/LP-0001.md index 6c2b819..d08ea39 100644 --- a/prizes/LP-0001.md +++ b/prizes/LP-0001.md @@ -1,97 +1,151 @@ --- -dependencies: [] +# This front matter is for internal reference and tooling only. It does not +# form part of the Specification and is not directed at Participants. +dependencies: + - id: LP-0021 + reason: NFT support and private ownership proofs for a wallet and Wallet Provider SDK matching the criteria in LP-0021 --- -# LP-0001: Private NFT Ownership Proof [DRAFT] +# LP-0001: NFT Wallet Support and Private Ownership Proof [DRAFT] -**`Status: draft - pending NFT Program readiness`** **`Logos Circle: N/A`** ## Overview -Token-gating is everywhere — allowlists, governance votes, exclusive channels — but today it requires revealing exactly which token you hold. This prize is for a ZK-based membership proof system that lets a user prove they own *some* NFT from a collection without disclosing *which one*. +This prize is for a LEZ wallet and Wallet Provider SDK matching the criteria in [LP-0021](LP-0021.md), covering **non-fungible assets**: owning, transferring, and displaying NFTs from the token program, exposing them to third-party dApps through the Wallet Provider SDK, and a privacy-preserving way to prove collection membership: proving you hold *some* NFT from a collection without disclosing *which one*. -The result is a reusable primitive: a Logos Execution Zone (LEZ) contract and a client-side proving workflow that any dApp can integrate to offer privacy-preserving token-gated access. +LP-0021 deliberately left NFTs out of its criteria so a winning team could ship a fungible-asset wallet quickly. This prize sets out criteria that fill that gap and turn it into a token-gating primitive that any Logos dApp can consume. ## Motivation -Current token-gating solutions force users to sign messages that expose their wallet address and the specific token they hold. This leaks on-chain identity, enables correlation attacks, and undermines the pseudonymity that many users rely on. A ZK membership proof — where the proof attests "I own a token in this collection" without revealing which one — is a natural fit for Logos' shielded execution model and closes this gap cleanly. +Token-gating is everywhere (allowlists, governance votes, exclusive channels), but on most chains it requires revealing exactly which token you hold. Users sign messages that expose their wallet address and the specific token, which leaks on-chain identity, enables correlation attacks, and undermines the pseudonymity many users rely on. -A competitive prize is the right mechanism here because the problem is well-specified but the implementation space is large: circuit design, nullifier schemes, Merkle tree construction, and gas cost trade-offs all admit multiple valid approaches. Competition surfaces the best solution. +Logos' shielded execution model closes that gap naturally, but only if a wallet actually exposes it. A proof primitive nobody can reach from a wallet does not get adopted, and NFT support that cannot prove anything privately is just a picture gallery. LP-0021 established the criteria for the wallet, Wallet Provider SDK, and approval flow these build on; this prize treats that as given rather than re-specifying it. Shipping both together is what makes private token-gating something a dApp developer can integrate in an afternoon rather than a research project. + +Submissions to this λPrize are welcome from the LP-0021 winning team or from a different team building a new codebase or however a team may wish to approach it. Submissions must be MIT and Apache-2.0 licensed either way (see [Eligibility](#eligibility)). ## Success Criteria +> The criteria below are a **minimum**, not a specification of the finished product. A submission is welcome to go beyond them wherever a team judges it necessary to win adoption: further features, a different structure, or a broader scope than this prize describes. Additional work neither substitutes for the criteria below nor counts against a submission. The [Adoption](#adoption) criteria are what the prize ultimately turns on, and teams are the better judge of what real users will need. + ### Functionality -- [ ] A user holding any NFT in a given collection can generate a client-side ZK proof of ownership on a standard laptop. -- [ ] The proof can be verified on LEZ without revealing the token ID or the holder's wallet address to the verifier. -- [ ] The system is resistant to proof reuse across contexts — a nullifier or domain-separation mechanism prevents the same proof from being replayed in a different gating context. -- [ ] A reference integration is delivered: a working demo of at least one token-gated action (e.g., allowlist registration or an on-chain vote) using the proof system. -- [ ] At least 5 independent NFT collections are deployed on LEZ testnet with the proof system integrated; the deployments must be reproducible and evidence must be provided. -- [ ] Full documentation and a clean public repository are delivered. +- [ ] **NFT ownership**: own, send, and receive non-fungible token-program assets on a LEZ zone, from both public and private accounts. +- [ ] **NFT display**: the wallet lists the NFTs held by each account, grouped by collection, showing at minimum the collection, the token identifier, and any metadata the token program exposes. Assets with missing or unresolvable metadata are shown as such rather than hidden or silently rendered as valid. +- [ ] **Collection view**: a user can see which collections an account holds assets in, and how many from each. +- [ ] **Wallet Provider SDK NFT APIs**: third-party dApps can enumerate an account's NFTs, query collection membership, and propose NFT transfers through the SDK, subject to the same approval flow as fungible transfers. +- [ ] **Private ownership proof**: a user holding any NFT in a given collection can generate a proof of collection membership that a verifier can check **without learning which token the user holds or which account holds it**. +- [ ] **On-chain verification**: the proof can be verified on LEZ, so a program can gate an action on collection membership. +- [ ] **Off-chain verification**: the same proof can be verified in application code, without submitting a transaction, so anything that receives a proof can check it for itself. Provide a library that performs the check and document what a verifier needs: the proof, the collection it is over, any public parameters, and whatever chain state must be read to establish the collection's ownership set. +- [ ] **Replay resistance**: the same proof cannot be reused across gating contexts. A proof accepted for one context must not be accepted for a different one. +- [ ] **Proof via the SDK**: a third-party dApp can request a membership proof through the Wallet Provider SDK, and the user is shown an approval prompt identifying the requesting dApp, the collection being proven, and what the proof discloses, before any proof is generated. +- [ ] **Proof requests stand alone**: requesting a membership proof is its own SDK capability, independent of account access. A dApp that has been granted only a proof request must not thereby learn the account address, the account's balances, its NFT holdings, or the specific token proving membership, and must not be able to enumerate accounts or propose transactions. A wallet must not require the user to grant account access in order to produce a proof. +- [ ] **Token-gating mini-app**: a reference application, built on the SDK, that gates an action on private collection membership, going through the full connect → approval → proof flow without requesting account access. It must demonstrate **both** ways a proof gets consumed: + - **On-chain**: the proof is passed as input to a reference LEZ program, which verifies it and gates an action on the result. Each gated action carries a unique identifier for the given LP submission, so that activity can be attributed to the submission that produced it. This is the flow that produces the on-chain gated actions counted in the adoption criteria below. + - **Off-chain**: the mini-app verifies the proof it received from the Wallet Provider SDK in its own code, with no transaction and no server in the path, and shows the user the outcome: whether the proof is valid, and what it establishes (the collection proven) as distinct from what it does not reveal. This is the worked example a developer copies to verify a proof wherever they receive one. + + It serves as the canonical integration example for third-party developers. +- [ ] **Testnet 0.3**: the wallet operates end-to-end against the canonical Logos LEZ zone on Logos testnet 0.3. If the foundation this prize builds on has already moved to a later testnet, that target takes precedence. ### Usability -- [ ] Provide a module/SDK that can be used to build Logos modules for interacting with the program. -- [ ] Provide a Logos Basecamp app GUI with local build instructions, downloadable assets, and loadable in Logos app (Basecamp). -- [ ] Provide an IDL for the LEZ program, using the [SPEL framework](https://github.com/logos-co/spel). +- [ ] Provide a module/Wallet Provider SDK usable by other Logos modules and third-party dApps to query balances, request account access, and request transfers and smart contract interactions, covering non-fungible assets in addition to the functionality set out in [LP-0021](LP-0021.md). NFT support is additive, not a replacement. +- [ ] The Basecamp app GUI and CLI cover NFT holdings, NFT transfers, and membership-proof generation, in addition to the functionality set out in [LP-0021](LP-0021.md). +- [ ] Logos Basecamp modules (core and ui types) are published to a module catalog: a fork of [`logos-modules-release-base`](https://github.com/logos-co/logos-modules-release-base), publishing releases via [`logos-modules-release-action`](https://github.com/logos-co/logos-modules-release-action). The catalog's `logos-repo.json` URL must be included in the submission so evaluators can install the module through the package-manager UI / `lgpd`. +- [ ] Approval prompts for NFT transfers clearly identify the requesting dApp, the target account, the collection, and the specific asset leaving the account. Collection-wide approvals, if supported, must be distinguishable from single-asset approvals in the prompt, so a user does not grant a whole collection while believing they granted one token. +- [ ] Approval prompts for proof requests state what the proof reveals and what it does not, in terms a non-expert can act on. A proof-request prompt must be visibly distinct from an account-access prompt, and must not grant account access as a side effect of approving a proof: where a dApp asks for both, the user can approve the proof and decline the account access, and each is approved separately rather than as one bundled permission. +- [ ] **Permissions are legible and revocable.** The user can see, per dApp, which capabilities have been granted (proof requests, account access, NFT enumeration, transaction proposals) and revoke any of them individually. A granted capability must be identifiable by what it discloses, not only by an API name. +- [ ] **Program source verification.** The approval prompt must show the user the program's source-verification status for the program being called. A program registry that meets or is similar to the specifications of [LP-0023](LP-0023.md) will be suitable. +- [ ] **UX quality.** NFT browsing, transfer, and proof generation must be polished and usable by a non-expert: coherent navigation, comprehensible previews, and clear error/pending states. This is judged against overall impression rather than a checklist: evaluators will use the wallet as a normal user would. +- [ ] **Integration guide.** Documentation covers how a third-party dApp adds private token-gating: the SDK calls, verifying a proof on-chain and in application code, what a program author must do to gate on collection membership, and how to request a proof without requesting account access. ### Reliability -- [ ] The system handles proof generation failures gracefully and surfaces a clear error to the user. -- [ ] The verifier program returns deterministic, documented error codes for all invalid-proof scenarios. +- [ ] Proof generation failures surface a clear, actionable error to the user rather than an opaque failure or a silently unproven state. +- [ ] Verification returns deterministic, documented outcomes for invalid-proof scenarios, so an integrator can distinguish "not a member" from "malformed proof". The on-chain verifier and the off-chain library agree: a proof accepted by one is accepted by the other, and both reject the same proofs for the same documented reason. +- [ ] A dApp cannot generate a membership proof without an explicit user approval for that request, and cannot enumerate a private account's NFTs without an explicit user approval for that account. +- [ ] The privacy property holds against the verifier, against an observer of the chain, and against the requesting dApp: none learns the specific token or the holding account from a valid proof. The submission must state its security assumptions and any trusted setup explicitly. +- [ ] The reliability criteria set out in [LP-0021](LP-0021.md) are met: wallet state survives restarts, no mandatory external services, and any remote persistence uses Logos Storage with client-side encryption. +- [ ] **Fetching media from centralised services is optional and disableable.** NFT metadata and media (images, video, audio) often live off-chain. If the wallet fetches them from a centralised service (an HTTP host, a gateway, a CDN, a hosted pinning or indexing API), that fetching must be disclosed, must be disableable by the user, and the wallet must remain fully functional with it disabled, listing the affected assets by collection and token identifier rather than failing or hiding them. Fetching must not leak which account holds an asset to the operator of that service: the user is told what a fetch discloses, and centralised media services are never contacted for a private account without the user turning it on. Fetching over a decentralised network the user participates in, such as Logos Storage, is not subject to this criterion. +- [ ] **Large metadata and media on Logos Storage.** The wallet can upload and download NFT metadata and media of a size typical for image assets to and from **Logos Storage**, so a collection can be published and displayed without depending on a centralised host. Document any size limits observed and how the wallet behaves when an asset exceeds them. ### Performance -- [ ] Document the compute unit (CU) cost of each on-chain operation on LEZ devnet/testnet. Note: LEZ's per-transaction compute budget may change during testnet. +- [ ] Proof generation completes on a standard laptop, without specialised hardware. Document the time taken and the machine it was measured on. +- [ ] Document the compute unit (CU) cost of on-chain verification on LEZ testnet. Note: LEZ's per-transaction compute budget may change during testnet. ### Supportability -- [ ] The program is deployed and tested on LEZ devnet/testnet. -- [ ] End-to-end integration tests run against a LEZ sequencer (standalone mode) and are included in CI. -- [ ] CI must be green on the default branch. -- [ ] A README documents end-to-end usage: deployment steps, program addresses, and step-by-step instructions for interacting with the program via CLI and Basecamp app. -- [ ] A reproducible end-to-end demo script is provided and works against a real local sequencer with `RISC0_DEV_MODE=0`. -- [ ] A recorded video demo of the end-to-end flow is included in the submission; the recording must show terminal output (including proof generation) to confirm `RISC0_DEV_MODE=0` was active. +- [ ] Deployed and tested against Logos testnet 0.3 (the Logos LEZ zone). +- [ ] Logos Basecamp modules are built with [`logos-module-builder`](https://github.com/logos-co/logos-module-builder) (`mkLogosModule`) and can be installed on both Linux and MacOS desktop platforms. +- [ ] End-to-end integration tests run against a real sequencer (standalone mode) and are included in CI; CI is green on the default branch. +- [ ] README documents setup, NFT management, proof generation, media storage and any fetching from centralised services the wallet performs, and step-by-step usage via CLI and Basecamp app. +- [ ] A reproducible end-to-end demo script works against a real local sequencer, with proving enabled rather than a development/mock proving mode, and covers the full flow: proof generation via the SDK without account access, consumption on-chain, and verification in application code. Its output must make clear that proving ran for real. +- [ ] Wallet Provider SDK documentation covers the token-gating mini-app as a worked example of connect → approval → proof → verification, on-chain and in application code, and documents which capability each SDK call requires and what it discloses. + +### Adoption + +> These metrics measure traction attributable to a given submission for this prize, incremental to whatever the underlying LP-0021 wallet already accrued. Re-citing LP-0021's numbers does not satisfy this section. +> +> **All of the following are required in addition to the FURPS criteria above.** We publish the dimensions we look at, but hitting a raw number is not by itself sufficient (see [Terms & Conditions](../TERMS.md) for the evaluation policy that applies to all prizes). Evaluators will inspect commit histories and the posting history of vouching accounts. Volume that is clearly manufactured (fresh accounts, purchased engagement) does not count, regardless of the headline number. +> +> **Who the baseline wallet criterion applies to.** A submission from the **team that won LP-0021, continuing that same wallet/SDK codebase**, has already demonstrated baseline wallet adoption: the baseline criterion below is **waived**. Every other submission **must meet it** through its own submission. That covers a different team, and the LP-0021 winning team shipping a wallet/SDK not descended from their own merged LP-0021 solution. All other criteria below apply to every submission. + +- [ ] **Baseline wallet adoption.** Waived for the LP-0021 winning team continuing that codebase (see above). Otherwise: **50 on-chain testimonials** on the LEZ zone via the LP-0021 testimonial mini-app, from **at least 50 distinct accounts**, same anti-Sybil standard as LP-0021. +- [ ] **5 NFT collections** deployed on LEZ testnet by parties independent of the submitting team, held and displayed correctly in the wallet. Collections deployed by the submitting team to demonstrate the feature do not count toward this number. +- [ ] **3 third-party developers**, independent of each other and of the submitting team, have each shipped a functional Logos Basecamp app (a **ui type** Logos module, per the module-catalog requirement above) that uses the NFT or membership-proof capabilities from this prize's SDK, not merely the fungible-asset SDK set out in LP-0021. Apps that only use the SDK outside a Basecamp app do not count. Each app must be publicly hosted on a mainstream forge (GitHub, GitLab, Codeberg, etc.) with a clear, genuine commit history: development spread over time by a real contributor, not a single bulk import. +- [ ] **100 on-chain gated actions** performed through the token-gating mini-app, each verifying a private membership proof on the official Logos zone, from **at least 100 distinct accounts**. Accounts with no prior unrelated testnet activity carry little weight. The official testnet zone is `https://testnet.lez.logos.co` (explorer: `https://explorer.testnet.lez.logos.co/`); the exact endpoint will be confirmed when this prize opens. +- [ ] **Sustained gating activity**: the 100 gated actions must be spread over **at least 2 months**, with **at least 20 in each of those months**. A single burst of activity does not qualify, however large. Each gated action carries the submission's unique identifier and is timestamped on-chain, so this is verified directly from chain data. +- [ ] **20 testimonials on Discord** and **20 on Twitter/X** specifically describing use of the NFT or private token-gating features. Testimonials should describe what the person actually did with them; account history will be checked. Sharing screenshots of the wallet in use is encouraged. ## Scope ### In Scope -- ZK circuit(s) implementing the membership proof over an NFT collection's ownership set, targeting the Risc0 proving stack. -- A LEZ verifier program (Rust) that accepts and verifies proofs on-chain. -- A client-side SDK or CLI tool for proof generation. -- A reference integration demonstrating at least one token-gating use case (allowlist, voting, or access control) on LEZ testnet. -- Documentation covering the cryptographic approach, any trusted setup requirements, and an integration guide. +- A wallet module matching the criteria in LP-0021, covering non-fungible token-program assets: ownership, transfer, display, and collection grouping, for public and private accounts. +- A Wallet Provider SDK matching the criteria in LP-0021, covering NFT enumeration, collection queries, transfer proposals, and membership-proof requests. +- Upload and download of NFT metadata and media via Logos Storage, with any fetching from centralised services disclosed and disableable. +- A membership-proof scheme over an NFT collection's ownership set, with client-side proof generation. +- A LEZ verifier that programs can call to gate an action on collection membership, and a library that verifies the same proof in application code. +- A token-gating reference mini-app built on the SDK. +- A CLI and Basecamp app GUI covering the above. +- Documentation covering the cryptographic approach, security assumptions, any trusted setup, and an integration guide. ### Out of Scope +> Not evaluated and not required, rather than forbidden. A submission may include any of the following if a team judges it useful for adoption; it will not earn or lose points for them. + +- The Logos blockchain wallet, staking, bridging, and multi-zone configuration, covered by [LP-0022](LP-0022.md). +- Designing or implementing the token program itself. The wallet integrates with the existing/reference implementation. +- NFT minting flows, marketplaces, listings, or royalties. - Multi-chain or cross-chain ownership proofs. -- A polished consumer-facing UI — a working demo is sufficient. -- Ongoing maintenance or security audits beyond initial delivery. +- Hardware wallet integration. +- Portfolio analytics, price feeds, or fiat on/off-ramps. ## Prize Structure -- **Total Prize:** $TBD +- **Total Prize:** $5,000 - **Effort:** Medium ## Eligibility -Open to any individual or team. Submissions must be original work. Teams must hold the rights to all submitted code and agree to license it under MIT or Apache-2.0. +Open to any individual or team. A submission must build on a wallet, Wallet Provider SDK, and approval flow with criteria that match those set out in LP-0021. Teams who have provided a Submission to LP-0021 may build on their Submissions as part of the Submissions for LP-0001. Submissions must be original work. Teams must hold the rights to all submitted code and agree to license it under MIT and Apache-2.0. ## Submission Requirements -- Public repository containing all circuit code, LEZ program code, and client-side tooling, licensed under MIT or Apache-2.0. -- Deployment of the verifier program on LEZ testnet, with a verified program ID. -- End-to-end demo video in which the builder narrates what they built and why, walks through the architecture and key implementation decisions, and demonstrates proof generation and on-chain verification for at least one token-gating use case. A silent screencast is not sufficient (see [demo requirements](../README.md#evaluation-policies)). -- Reproducible deployment steps and evidence for at least 5 NFT collection deployments on LEZ testnet with the proof system integrated. -- A write-up covering: cryptographic approach, proving system used, Merkle tree construction, nullifier/domain-separation scheme, security assumptions, known limitations, and integration instructions. -- Gas cost benchmarks for on-chain verification. +- Public repository with the wallet module, Wallet Provider SDK, CLI, token-gating mini-app, LEZ verifier, off-chain verification library, and Basecamp app GUI under MIT and Apache-2.0. +- Deployment of the verifier on LEZ testnet, with a verified program ID. +- A write-up covering the proving approach, how collection membership is represented, the replay-resistance mechanism, security assumptions, and known limitations. +- Proof generation timings and on-chain verification cost benchmarks. +- Evidence for each adoption criterion: links to the 5 independent NFT collections, the 3 third-party SDK apps and their repositories, the wallet repository, the on-chain gated actions (with the submission identifier and per-month counts so the sustained-activity criterion can be verified), and the Discord and Twitter/X testimonials. +- FURPS self-assessment as part of the solution (see [solution template](../solutions/LP-0000.md)). - GitHub issues open for any problem encountered with Logos technology. ## Evaluation Process -Submissions are evaluated first-come-first-served against the success criteria. The first submission that satisfies all criteria wins. +Submissions are evaluated first-come-first-served against the success criteria. The first submission that meets all criteria wins. + +Because the adoption criteria require sustained activity over at least two months, a submission cannot qualify until that window has elapsed. Builders are encouraged to ship early and start accruing adoption while continuing to develop, rather than treating the build and the adoption push as sequential. Evaluators will independently clone the repository and run the demo script from a clean environment; the script must succeed without modification. Evaluators may also ask technical follow-up questions to verify authorship and understanding of the implementation. @@ -102,8 +156,40 @@ The following policies apply to all prizes (see [evaluation policies](../README. ## Resources -- [LEZ Github repository](https://github.com/logos-blockchain/logos-execution-zone) +- [Logos Execution Zone repo](https://github.com/logos-blockchain/logos-execution-zone/) +- [LEZ programs repo](https://github.com/logos-blockchain/lez-programs/): includes the token program +- [LP-0021](LP-0021.md): LEZ Wallet and Provider SDK +- [LP-0022](LP-0022.md): Combined Blockchain and Zone Wallet +- [LP-0013](LP-0013.md): Token program improvements (authorities) +- [LP-0014](LP-0014.md): Token program improvements (ATAs + wallet tooling) +- [LP-0023](LP-0023.md): Program registry with verified builds for LEZ programs (bytecode-to-source). + +> The Resources referred to are for informational purposes only and are intended solely as guidance regarding tools or other artefacts that may be relevant to preparing a Submission for a Prize. The Resources may include, or may refer to, earlier published Prizes or Specifications, some of which may have received Submissions. Logos does not endorse or approve, and makes no representation regarding any Submission or referenced material. Ultimately, it is the Participant's responsibility to determine whether, and how, if at all, to use any Resource. ## Potential for Subsequent λ Prizes -TBD \ No newline at end of file +This prize covers the **first adoption tranche** for NFT support and private token-gating. A follow-up λPrize is expected with higher adoption thresholds, adapted to the phase the network is in at that time, and potentially extending private membership proofs across multiple zones once a wallet matching the Specifications of [LP-0022](LP-0022.md) exists. + +This prize targets Logos testnet 0.3. Should a future testnet version introduce breaking changes to the token program or the proving stack, a subsequent λ Prize may be opened to cover adaptation. + +--- + +**Note:** The Specification in this Prize describes an outcome that Logos intends to benefit the Logos ecosystem. It sets out criteria and certain requirements a Participant should fulfill in order to potentially be eligible to be awarded a Prize amount, and is not intended to be an instruction or to direct a Participant's initiative or approach. They are guided by existing approaches and implementations in other mature blockchain systems and their ecosystems, as well as by functional requirements particular to the Logos technology stack or perceived usefulness to such stack or the wider community building on it. + +Prizes may contain adoption criteria which are intended to demonstrate real world-interest and the extent to which others are building on, testing, or experimenting with a submission. It may further indicate a submission's potential usefulness to the Logos technology stack and the community around that. + +A Prize may also refer to the criteria specified in a previous Prizes solely for the purposes of identifying criteria applicable to an Artefact or other component of a Submission for the current Prize. Such references do not require a Participant to use, extend, modify or otherwise rely on any previous code, implementation or Submission associated with a previous Prize. A Participant must develop and submit a Submission that satisfies the requirements of the current Prize, including any criteria from or identified by reference to the previous Prize. + +Logos does not endorse, approve any Submission and does not guarantee that they are safe, reliable, or fit for any particular purpose. Logos further makes representation as to the legal or regulatory treatment of this Specification or any implementation of it in any jurisdiction. Anyone interacting with Submissions should do so cautiously and at their own risk and should treat them as unverified code. + +Participants act independently, voluntarily and at their own initiative in connection with their Submissions and are solely responsible for: + +1. assessing the risks and implications of their Participation in the Program and of any Artefacts that form part of their Submission; +2. determining whether to obtain independent professional advice; +3. complying with all applicable laws to them and in connection with the Program, including, where relevant, any licensing, registration, sanctions or anti-money laundering obligations that may arise from operating any software-as-a-service or business. + +Artefacts developed by Participants in connection with the Program are published and maintained by Participants and not by Logos or its Affiliates. Logos and its Affiliates do not build, host, maintain, deploy, operate, use or control any Artefacts arising out of any Submission. + +Participants or other persons who choose to build upon, host, maintain, deploy, operate, use or publicly promote any Artefacts, do so at their own risk and as a principal and in their own name. Any such persons are further solely responsible for complying with any legal or regulatory requirements that apply to them with such use. Logos does not make any representation, provide any advice or assume any responsibility regarding the use of such Artefacts, or any determination of compliance with applicable law or regulation. + +For further details of the above and what terms and conditions apply to a Participant, please refer to the [λPrize Program – Terms & Conditions](../TERMS.md).