Python integration for NEAR blockchain, similar to web3.js or near-api-js.
Python is most used by data analyst (scan on-chain data flow), exchange integrations (a lot of centralised exchange are partially written in Python) and DeFi trading bots.
A standard SDK for mobile wallets and dApps to communicate.
Note: WalletConnect Foundation is open for grants. WalletConnect protocol is already used by more than 30 wallet apps. The protocol itself is chain agnostics, used e.g. by BinanceChain (the Cosmos one), so if NEAR is looking to gain support in mobile wallets, it is best to be done through existing WalletConnect SDKs.
My understanding is that it is not the case right now.
Trust Wallet has a custom implementation for BinanceChain that is not spec compliant based on their feedback.
There is v2 spec, but I’m not sure what the state is.
Yes, there is still some work to do for v2. But however, the foundation is there:
dApps and wallets have ready SDKs
RPC payloads go to both directions encrypted
Adding custom requests is easy
It would be a no brainer for NEAR to start expanding the wallet support using WalletConnect. NEAR specific bits need to go into v2 spec any case, so better try to do a PoC and give feedback for the spec, making it very easy for the wallets to adopt NEAR.
I believe an extension-based wallet adds another option to HW, phone wallets and the Near Wallet. A lot of ETH users are used to Metamask, having something similar for NEAR would be of great help to make them feel at home in NEAR
I’m working on that actually. It already imports accounts in read-only mode and can auto-locate your lockup contract. I’m about half the way to a beta release
An intermediate SDK option between Rust and AssemblyScript
This is a long haul proposal, but I think we can bring dotnet/C# into the mix with Rust and AssemblyScript, so contract developers have another option for NEAR development.
Microsoft is investing heavily in WASM and its dotnet open source initiative, so the basis are there and it’s the right time to do this. Blazor is their hot-new framework, and it allows you to write C# code that runs in the browser. So if we can provide C# support to develop NEAR smart-contracts (all compiles to WASM), developers would be able to create amazing web3 SPA Apps and the smart contract all using the same language.
It’s not easy and it’s a ton of work, we need a medium-sized team to even start this project, but I think it’s doable. I have in my company several C# experts which I can use if we can secure a grant.
The idea is to eventually build a near-sdk-dotnet, documentation, examples, etc, so C# developers can use all the dotnet tools, IDEs, and tooling to develop for NEAR
It’s common that some transactions need to be executed at some specific point of time or based on some on chain condition.
Chain itself doesn’t have such function, hence external actor must be used. For example bite in Maker if CDP is under collateralized or finish contract deployment at specific time if delay has completed.
Such service can be a decentralized with smart contract that can register which transaction must be sent and when. Tx payment and some reward also gets attached for the sender.
Any other participant in the network than can send a tx to this contract. Contract verifies if condition is met and then would dispatch the scheduled transaction.
This can be expanded into full IFTTT service.
A core benefit, is that smart contracts themself can “schedule” call to themself for later.
This creates some form of agency in the contracts.
Tool where community can see official circulating supply of NEAR tokens. In this case, we’ll be able to ensure that websites like coinmarketcap can show correct info about our circulating supply and valuation that they derive from that (currently information is misrepresented on Coinmarketcap and “cost” us about 20ish position in their ranking). Zavodil and Stardust’s website show different info about our circulating supply. Telegram bot shows a number that’s different from those websites.
So glad to discover this. I’ve been floating this idea with Evgeny, Vlad, and my friend Trevor. Very interested in making this happen. I think this could also be a great case study for the profitability of a contract that is only funded by the 30% gas benefit.
I don’t even think it needs to live only on 30% gas. Because user/the other contracts pre-pay for transaction fees - they can actually pay more than required. The left over will go to the contract (developers or token holders). For example https://gelato.network/ is Ethereum IFTTT here.
@hodlr
A more specific form and layout for all the ideas is coming. In the mean time, just posting here short description + a doc with spec and work scope works as well.
Once we have our Wallet SDK we need libraries providing a nice login experiences like for wallet such as WalletConnect, Torus, Fortmatic, Portis etc. For dapp developers this makes it very easy to integrate wallet support in no time.
I can really be a PITA to also spend time on thinking on all the edge-cases for notifications. This library does that very well and makes it possible to ship with working notifications in no time