Problem: Truf Network need to own Solidity Smart Contracts

[MicBun]

If I understood the specs correctly, the scope is also to propose a permissionless initial billing strategy, whereas, on Nuon, it could be a contract whitelisted for the Nuon owner/consumers, which simplifies.

@outerlook - after a little looking, and since we proceeding with the CF approach, we're going to need to create our own Solidity Smart Contracts.

This is primarily because CF has a whitelisting mechanism for "consumer" contracts.
Furthermore, there's a cap of 100 "consumer" contracts.

Therefore, our new contract will be a single "consumer", that allows for any number of calling contracts to request Truf data.

The function of these Contracts are to:

1. Proxy incoming calls from foreign contracts to Chainlink
   1. Here, calling contracts must transfer TRUF tokens to the Proxy in order to facilitate the Chainlink request.
   2. We must ensure this Proxy is funded with LINK tokens too.
   3. The TRUF token will remain in the Contract - but there must be a Administrative function to withdraw these tokens to a wallet that is predetermined by the Admin. ie. Admin wallet can only trigger a function to withdraw to a SAFE multi-sig.
2. Facilitate billing dynamics.
   We can either use a hook paradigm where upgradeability is only enabled on the hook contract, or we can couple the contracts and make them both upgradeable.
   The latter is a little less secure, but we're going to need to manage security around Admin keys anways.
   I think zero-trust Admin mechanisms are required - I have plans for this, but in the meantime, there should really be only a single person with access to the Admin wallet....
   Or better yet, we make the SAFE wallet that is designated to receive the TRUF tokens as immutable...

@Jarryd-pretorius - What's your take on this?
Zero-trust protocol around key management is something I can propose, but do you have suggests for interim security processes around super-sensitive key management (ie. Contract Admin)?

The best approach to execute this is for Raffael or Michael to try their hand at the Solidity Contracts.

Then I'll review the Contracts before we deploy them.

Additionally, these Contracts will need 100% unit test coverage (ideally in Foundry, but can also be in Hardhat)
Furthermore, deployment scripts are necessary for the Contracts.

---

Alternative 1: We manually whitelist "consumer" contracts (customers) to use our CF Oracle.
The customers essentially pay us off-chain, and use LINK to execute directly against Chainlink Contracts.

---

Alternative 2: Giving the CF code to customers to deploy themselves... essentially handing over Serverless Oracle management.

---

Of course, the first strategy gives us more control over automated TRUF powered billing of data across Chains... but has more technical overhead.

Originally posted by @rsoury in #547 (comment)

[MicBun]

Hi @rsoury,

I've moved our last conversation here. If it's more convenient, could you add your suggestions to the spec document? It might also make sense to separate them as a distinct Goal since it feels like a significant task on its own. Let's keep the Goal section clean. Thanks!

[outerlook]

Alternative 2: Giving the CF code to customers to deploy themselves... essentially handing over Serverless Oracle management.

Although I prefer this option, my concern is distributing the current risks of secrets management within CF. I think it wouldn't be comfortable to suggest users use their whitelisted private key (which may contain assets) with CF DON encryption solution.

Whereas, for us, it might be less risky as we'll create a single-purpose wallet with read access and no assets.

[markholdex]

@MicBun @rsoury @outerlook, can you guys elaborate on your concerns in the spec doc? Developing a smart contract is not that unknown. We already have a couple developed with Chainlink Functions. I want to address the concerns in the doc so we can comment on specific ideas.

[outerlook]

Alright! The concern was more related to (1) authorization (2) billing dynamics. If we all agree with having a whitelisting procedure on our contract and leave on-chain billing for a later stage, it's fine to go. If someone isn't sure, we create specs to discuss it better.

Before this, I intend to solve https://github.com/trufnetwork/truf-data-provider/issues/337 with a minimum testnet deployed contract (owner-only procedures). Solving this one should be an incremental effort.

I also feel that we can start #699 data contracts in parallel if we have the capacity since at least developing and testing the kf files doesn't depend on EVM part

[rsoury]

@markholdex - It's not a matter of Solidity being unknown. It's the overhead in deploying a new billing protocol that's the issue, especially since we're pre economic model.

As per @outerlook's comment, we're proposing an off-chain billing paradigm.
https://irys.xyz/ successfully launched with this strategy, and it helped them cover more blockchains way faster too.

I've added to the Spec here: https://docs.google.com/document/d/11RFE6YhivcCwkZfj95wO9FV61vym7VBUkwbsYvuSm4Q/edit?tab=t.0#heading=h.wobg1jf6jzce

Please suggest/critique, etc.