This seems to be a similar project to Nois on Cosmos. Randomness is something that projects will require in order to ensure fairness in their applications. Based on the previous case, Nois, we would like to ask some questions about adoption, compatibility and future support which were the main issues that this approach had on Cosmos.

1. Adoption. The adoption of Nois was limited mostly due to the Luna collapse which affected Cosmos the most and it never recovered. But the most evident issue outside the macro picture was that some blockchains like Stargaze used Nois as a source of randomness whereas others, specially dapps just went straight to the Drand API to connect to the source of randomness thus bypassing the blockchain completely. This makes it evident that the clients for Ideal would also be limited to parachains and large projects. A secondary limiting factor was that Nois was compatible mostly for IBC blockchains. How is Ideal Network planning to reach as many projects as possible? Within Polkadot and outside of it (more on this on paragraph 2).
2. Compatibility. Based on the paragraph 1, compatibility outside of IBC chains was the second most important factor against the expansion of Nois. Would Ideal Network be considering actively integrating with Hyperbridge and/or Snowbridge to also "export" randomness from Ideal Network into supported EVM chains? It seems like the latency and transfer times would make it possible to relay a message through Hyperbridge to EVM chains. We need to put an emphasis on actively integrating as some referenda in the past have just agreed to some terms without ever delivering them.
3. Future Support. We have seen other projects to move goalposts after funding as well as abandoning the project completely as soon as it's delivered so we need to have crystal clear assurances about the future development costs of Ideal network and the maintenance and support costs both in human terms and monetary terms. We are policing heavily against abandonware, unknown maintenance costs and against increase of costs of future deliveries. So knowing these costs in advance would help. In the same vein, is Ideal considering funding through a token launch like Nois did? Or does it plan to remain a common goods project within Polkadot's treasury support? Tokenization after failed public funding is understandable but tokenization without treasury swaps and with treasury support is hard to vouch for.

Looking forward to hearing your answers and future plans.

Hey,
From proposal:
"Ideal Labs will maintain a public Kanban board on GitHub to provide real-time tracking of progress, complementing the regular communication updates."

Can you link this kanban/github board?

Another question:
How have you guys collaborated with NIST?
The link(https://csrc.nist.gov/Projects/interoperable-randomness-beacons) mentions Cloudflare and Crypto reading club

Indeed providing unpredictable randomness to contracts on AssetHub would be hugely beneficial. Just some questions.

You are saying that you would provide a consumer pallet that would handle the XCM subscriptions to Ideal network. You also state that you will provide a ink! contract (or rather library I would presume) that abstracts away the XCM communication with the IDN Manager Pallet.

Are those stand ins for each other? Meaning the contract library is used when your chain has pallet-revive but no consumer pallet? Because I would expect the consumer pallet to expose its randomness as pre-compile making any XCM within the contract not unnecessary.

Lucky Friday have voted AYE Please consider this a temporary notification after our vote has gone on chain. If you would like additional feedback on our rationale for this vote, please join our OpenGov Public Forum on Telegram here: https://t.me/+559tyPSfmGg0NzUx

Lucky Friday provides feedback once per week (Fridays) if specifically requested in our OpenGov Public Forum, and we respectfully ask that all proponents of referenda interact with us here for the sake of transparency. Please tag our Head of Protocol Partnerships “Phunky” with your referendum number so that he can gather the relevant commentary from our internal deliberations.

Dear @Ideal Labs,

Thank you for your proposal. Our vote on this proposal is AYE.

The Medium Spender track requires 50% quorum and simple majority according to our voting policy. This proposal has received five aye and zero nay votes from ten members, with four members abstaining. Below is a summary of our members' comments:

The referendum received mixed feedback, with majority support for its potential benefits, particularly in bringing verifiable randomness to Asset Hub and enhancing network security. Supporters praised the team’s credentials, the reasonable funding request, and the innovation in providing a cost-effective alternative to existing solutions like Chainlink VRF. However, several members abstained, citing the need for more information or clarification on specific use cases and implementation details. Some noted a preference for a milestoned approach to the proposal, while others highlighted its potential to serve as critical infrastructure for the ecosystem. Overall, the proposal was met with cautious optimism and a call for further collaboration and refinement.

The full discussion can be found in our internal voting.

Kind regards,
Permanence DAO