I have an idea about how to implement it, using self-balanced binary trees. I still don’t know if the implementation will be efficient enough to make transfers but I presume it will be.
What about a non fungible token, where you can transfer them in batches as large as you want. They are like fungible tokens, but each individual token has a sequence number. Very much like dollar bills.
Is there any practical use case for such interface?
Some idea: you transfer some tokens through a bridge. The equivalent is minted in the other side of the bridge, but using this interface. Each token will keep track of the exact tx where it was deposited, and could be treated differently.
@mob yeah; that ain’t easy to do; but I have some idea.
The basic idea of how it works is that I do binary search finding the blocks where the nonces in your access key changes! Meaning that a tx was done from your account.
Ofc this means that you will only see txs signed by you; I plan to handle separately ft receivals; but in a similar way: tracking balance changes.
Notice that this explorer doesn’t use any other backend than a near rpc endpoint.
@mob here is the live demo:
https://near-explorer.github.io/#/marcelo.near
It may take some time to fetch your txs if there are too many! already have an idea to download faster the recent txs so we can get faster feedback.
@mob here is the live demo:
https://near-explorer.github.io/#/marcelo.near
It may take some time to fetch your txs if there are too many! already have an idea to download faster the recent txs so we can get faster feedback.
@rozbor I’ve looking for implementing a fair and decentralised casino for some time now.
NEAR exposed random numbers that can be used (with caveats).
The decentralised part would work as follows: everyone can put the money as the house; and gamblers play against that money (odds are always against gamblers ofc). This is a house contract; and audited games can use resources from the house.
While thinking of this; not only this mini-explorer can used this registry; but also other explorers; off-chain apps and most importantly wallets that are making you sign nearly opaque information.
However having a common registry requires an standard! Before jumping into developing a NEP; I'd love to get your input on this.
Here is a first iteration:
https://github.com/mfornet/near-mini-explorer/blob/master/library/transactions/ft_transfer_call.json
Here is the source code: https://github.com/mfornet/near-mini-explorer
The most exciting feature for me however; is creating an on-chain registry that allows me to understand the content of a tx; and display better information for it. Wether it is an NFT transfer; a near land interaction; a berryclub farming action or a swap in ref finance. Building this registry as a community would be great;
We just created a bounty program in Aurora. https://github.com/aurora-is-near/bounties.
Looking forward to meet engineers willing to contribute and get rewarded for that. If you are interested please ping me.
For now we just have one task. But feel free to explore open issues on Aurora repositories/ecosystem and ping me to open a bounty on those.
On the same line of this proposal: https://github.com/near/bounties/issues/15.
It would be nice to build signed proofs of events happening on near.social (like toots and maybe DM) so we can integrate them easily with contracts on NEAR. It will work with an oracle that verifies the content is signed by the platform. We still need to trust whoever runs the infrastructure doesn’t go rogue, but we can iterate on this later.
Which feature should we implement first in the Near.Social dApps catalog? #near-social
#intro I'm Marcelo, previously NEAR Core Engineer, and Rainbow Bridge 🌈 developer, currently hacking on Aurora as a lead of the protocol team.
I speak Spanish 🇨🇺 🇪🇸 and still enjoy participating in programming competitions.
Looking forward to connect with more members of NEAR ecosystem.
Aurora Protocol Team Lead, previously NEAR Core Engineer, Rainbow Bridge