Provide Default Sponsored RPC Endpoint in SDK

[cygnusv]

taco-web currently requires integrators to provide their own RPC endpoint when interacting for encryption & decryption. However, this endpoint is not used for adopter logic, but exclusively for TACo protocol (specifically, this endpoint should be Polygon Mainnet or Amoy). This is particularly confusing if developers are not using the same chain ecosystem that our protocol (currently Polygon).

Example from our docs:

const signerProvider = new ethers.providers.Web3Provider(window.ethereum);

// Protocol-exclusive RPC provider here !!!!!
const polygonProvider = new ethers.providers.JsonRpcProvider("https://polygon-amoy.drpc.org");

const message = "my secret message";
const ritualId = 6

// encrypt data
const messageKit = await encrypt(...);

This has caused recurring UX issues:

• Developers frequently connect to the wrong chain
• Incorrect RPC configurations cause hard-to-debug errors
• Rate limits and archive support vary between providers
• Increased support overhead for potential integration

Proposal: Introduce a default, protocol-sponsored RPC endpoint in the SDK. The API doesn't change much, since it's only a default: If no RPC is provided, SDK falls back to our managed endpoint, but of course, developers can override with their own RPC if desired. This is the same approach we currently have for Porter.

Sponsored endpoint may restrict usage to:

• Whitelisted protocol contract addresses
• Specific method selectors (optionally)
• Read-only calls

Estimated Monthly Infra Cost: Based on analysis of major RPC providers:

Provider	Monthly Cost
Alchemy	$49–$299
Infura / QuickNode	$50–$300
Blockdaemon / Chainstack	$20–$200

[theref]

i think this would be much better UX - why not just use a free public endpoint and make it clear that performance will be impacted?

[cygnusv]

why not just use a free public endpoint and make it clear that performance will be impacted?

why not indeed! We're already using public endpoints in nodes. Having said that, a TACo-managed endpoint would be interesting because we can in principle get better assurance. But we can have many options, anyway. In any case, the main point I was trying to make was to use a default.

[derekpierre]

Thanks for the great write-up.

Just to add background here of what the endpoint would be used for:

Access Control

• encrypt: one Coordinator call to obtain the DKG public key corresponding to the ritual ID.
• decrypt: Coordinator calls to obtain:
  • ritual ID from the public key
  • list of participants for ritual ID

Action Control
Perhaps we could potentially do the same for signing (but for Ethereum/Sepolia instead of Polygon)?

• Signing is slightly different in that, context parameters for conditions need to be populated before sending signing request, and to do so, users need to call ConditionContext.forSigningCohort(...) with a provider which gets the condition and determines what context variables are needed. This happens before calling signUserOp(...)_
• signUserOp: SigningCoordinator calls to obtain the following for the cohort Id:
  • signer set
  • threshold

--

Public RPC Endpoint as Default

Use of a public RPC default would be interesting from a simplicity standpoint.

My concern with the public RPC default is that if taco-web uses one and that endpoint is taken down / ceases to exist for some reason, then the application stops working because it never specified an endpoint, and then the only way to fix this situation is to...upgrade the application (?).

Technically, our default Porter endpoints have this same issue, but since we manage it that can be resolved, but the problem can still arise in a scenario where we are forced to take Porter down; it is one of the downsides of the strategy we took. That being said, the default Porter instances going down permanently would be an existential issue necessitating applications to upgrade, rather than some public RPC endpoint going out of commission.

This raises some design questions:

• Instead of a single default endpoint, would a list of default endpoints with some kind of automatic failover be good? Similar to what nodes use so we aren't reliant on just one and rate limits, blips in connectivity etc.?
• Is there a concept of runtime overrides for a typescript library running on node.js or in the browser or ...? Would that be localStorage? If so, then any default could potentially be overridden at runtime.
• Should the default endpoints be obtained from a specific location eg. github, sort of what we do with our nucypher/chainlist repos? In this case they can be remotely updateable without necessitating application changes. However, this seems a bit heavy handed for client-side library? Is it safe to do this within an application? Is this even a good practice?

TACo Managed Endpoint

Having a TACo-managed endpoint would be a more stable alternative, but then we are managing infrastructure (😅) and becoming more centralized. It would be moving us closer to the Porter model, which we've often discussed wanting to move away from once we resolve the TLS complexities and web-based application (self-signed certs etc); in an ideal world we've talked about not even needing Porter.