| Pages: [1] 2 :: one page |
| Author |
Thread Statistics | Show CCP posts - 0 post(s) |

TornSoul
BIG Libertas Fidelitas
|
Posted - 2009.09.24 19:16:00 -
[1]
Which businesses in EVE move alot of ISK?
By alot I mainly refer to lots of transactions - The amount of ISK involved is irrelevant.
And by move, I mainly refer to "pay out" ISK (to other characters)
The reason being that this is a manual task. (Recieving ISK can be recorded automatically thanks to the EVE API.)
So basically, who has to regularly (daily?) make alot of ISK payments to other players?
The only one I can think of at the top of my head is EOH. And I don't even know if it's "alot" - Is it 10 a day, 50, 200 or more? Would EOH reveal this number?
EBANK would be another candidate, if it was still operating. Historical numbers would be interesting none the less. Although with the discovered shoddy bookkeeping I don't know if such numbers are even available. But perhaps some former bankers can "guestimate".
Any others anyone can think of? (feel free to take a guess at the number of transactions as well)
-----
2nd part of this question would be:
If it *wasnt* a manual task to transfer ISK to another character - Would other existing businesses benefit (grow/gain more profit/more customers etc) if they did not have to do this manaully?
Which new businesses might spring into existence if this "barrier" didn't exist? (I have a drawer full of those myself)
----
Why am I asking?
Two fold:
Is there actually a substantial demand for being able to do this (transfer ISK to another character without manual labor - ie. automated) - Or is it just a few of us MD'ers who would think it would "be nice" to be able to? Given substantial demand (I kinda doubt it - But await the answers) a case might be made to try and get CCP to take a (2nd) look at it.
Secondly, a substantial demand (both from existing, and future businesses being enabled by this) will partly decide if a new business idea would be worth the effort to implement (again - I doubt it)
---
Awaiting some interesting suggestions.
BIG Lottery |

HawkBlade
|
Posted - 2009.09.24 19:42:00 -
[2]
I can't honestly answer your question because the possibilities are so many. Law of unintended consequences but applied in a positive manner. I've long asked for more financial mechanisms. All this talk about dynamic and expansive... just other forms of Pew Pew.
You know, I wonder if Bob hadn't lost their space and now have to take space back 1 tower at a time (if they can) would the developers be so animated about fixing SOV.
Any ex-Bob people willing to join the MD so we can get some lovin'? Or could you just share this link on MSN?
See my twitterings about Eve Online. Be the first to hear me toot.
|

TornSoul
BIG Libertas Fidelitas
|
Posted - 2009.09.24 19:59:00 -
[3]
Edited by: TornSoul on 24/09/2009 19:59:21
Originally by: HawkBlade I can't honestly answer your question because the possibilities are so many.
For the 2nd part of my question : Agreed. (as i said, got a drawer full of projects myself)
What about the first part of the question? Any existing businesses you could think of?
BIG Lottery |

HawkBlade
|
Posted - 2009.09.24 20:09:00 -
[4]
Originally by: TornSoul Any existing businesses you could think of?
Lotteries, manual bonds (like I always do). The key factor here is not what existing businesses do this already but in a severely crippled manner. It is how many other business models would be empowered by the increased ability. BTW as an added thought: Damn I wish there was some way to evemail shareholders. Eve mailing lists are hit or miss and having to eve mail them all directly or issue votes with info instead of actual options just cripples information dissemination. (Mild tangent me thinks.)
See my twitterings about Eve Online. Be the first to hear me toot.
|

HawkBlade
|
Posted - 2009.09.24 20:17:00 -
[5]
Originally by: HawkBlade The key factor here is not what existing businesses do this already but in a severely crippled manner. It is how many other business models would be empowered by the increased ability.
I think what you want is to develop a demonstrable argument in favor of getting Developer time towards a solution. I'm of two opinions on this: First: The best demonstrable argument is the stagnation that the current limitations have brought about. Peering forward, especially with such a creative and shifting mass as the Eve population, is fraught with error, peril, and a few delights. Making any case on prognostications will be weak though. Secondly: If you can add in some explosions, some pretty graphical animations, and the occasional scantily clad bimbo to the financial interface... you couldn't keep the Developers off of this. That is their targeted audience. Heck, in many cases they are their own targeted audience. Coding, or employment, at CCP doesn't make them smarter, wiser, or any more objective then the next "jenius" on the internet. In fact, from what we've seen they are exactly like the next "jenius" on the internet with only one exception: Their success or failures effect us. How they are most like those "jeniuses"? They pretty much don't care unless it effects their paycheck. Then they care a lot.
See my twitterings about Eve Online. Be the first to hear me toot.
|

TornSoul
BIG Libertas Fidelitas
|
Posted - 2009.09.24 20:20:00 -
[6]
Manual bonds - Agreed. I guess there's a couple of those.
Lotteries - The *recieve* alot of payments, but do hardly any pay outs (just to the few winners)
(and yes we agree it's the potential that's the really interesting part - But I'm also interested in current businesses as they could be used as "testbeds" should I go forward with this at all - I'd give that a 2% chance atm)
BIG Lottery |

HawkBlade
|
Posted - 2009.09.24 20:23:00 -
[7]
Originally by: TornSoul Lotteries - The *recieve* alot of payments, but do hardly any pay outs (just to the few winners)
That's the stagnation example. Many lotteries support multiple winners. But the limits make such things burdensome.
See my twitterings about Eve Online. Be the first to hear me toot.
|

Martosh Toma
Gallente Fraction Investment
|
Posted - 2009.09.24 21:02:00 -
[8]
from a workload perspective I can understand your sugestion, However, looking at how few people (by estimate) would use it compared to the total number of people that would be put at risk by it...
I think it is the fact that this ability does not exsist within eve is one of the reasons why a bank might be feaseble. Having a seperate system for wich you opt in as a user and control the risk you take (by how much you put in there) were you can buy goods for delivery, or do a distributed isk transfer (provided those options are implemented by the bank). a Contract api with a limited write option would complete it for webshops, and for distributed transfers it is not even needed.
I know this is a tangent, but I was thinking on something like this as an option for webshops. Scamming would be possible but all parties would have a reasoneble level of protection.... - unless the bank is scam but even then the risk is somewhat limited. Transaction flow example for such a webshop (the celivery contract type should be the only one possible to make trough the api)
Having an account with a bank you click buy (specefying delivery and stuff) on a webstore in the ingame browser Both the bank and the webstore are registred for the service. - (the bank has to accept the webstore and vice versa but that is their responsibility, not ccp's) Isk is withdrawn from your bank account and held in escrow by the bank A delivery contract is created: - private, buyer will accept listed goods for free in specified location before a specified date - (transaction code is returned to the shop and the bank) Manual delivery of goods by seller. (transaction change transmitted to creating parties) Buyer can accept or refuse. (transaction change transmitted to creating parties (bank and store)) Isk transaction in the banks system is completed as far as possible: - On accepting the order the isk in escrow with the bank is automatically released to the seller. - On a refused order the seller can release the isk back to the buyer automaticlly - Contracts that are overdue can be canceled (differend from refusing) releasing the isk back to the buyer (by the banking system) - In all other situations manual intervention is probebly required.
|

TornSoul
BIG Libertas Fidelitas
|
Posted - 2009.09.24 21:15:00 -
[9]
Originally by: Martosh Toma number of people that would be put at risk by it...
What risk? It's the ability to transfer ISK from your *own* wallet only. Say, using your existing full EVE API key credentials (or a new level of code - Say "admin" EVE API Key (In contrast to "full" and "limited")) Which can even be changed at the click of a button, without affecting your actual account credentails. (It's actually easier (less clicking) to change your EVE API code than your account code - Bit ironic )
Risk is not CCP's argument for not doing it. It's due to legal reasons... But as legal stuff is almost the definition of "elastic band" I'm fairly confident, if the will was there, that something could be worked out.
Originally by: Martosh Toma
webshops.
Bingo!
Nothing else needs to be said. Everything else follows from there. And it's *alot* (even left shar speachless - sorta )
BIG Lottery |

Hel O'Ween
Men On A Mission
|
Posted - 2009.09.24 21:30:00 -
[10]
Originally by: TornSoul
Originally by: Martosh Toma number of people that would be put at risk by it...
What risk?
Any application that implements these transactions will have bugs. Be it the software itself, the framework, 3rd party libraries, database system, server, hosting service used.
Given the criminal nature of gold farmers, they will actively seek for those security holes (or even buy them from those 0 day exploit market sites). Given the amount of ISK they could gather that way, we will experiencing exploits most likely sooner than later.
As nice and convenient such a feature would be for the loyal and lawful EVE player, I fear this will not happen anytime soon. -- EVEWalletAware - an offline wallet manager |

TornSoul
BIG Libertas Fidelitas
|
Posted - 2009.09.24 21:33:00 -
[11]
Edited by: TornSoul on 24/09/2009 21:34:26
Originally by: Hel O'Ween Given the criminal nature of gold farmers, they will actively seek for those security holes
Ok - I should probably have said "additional risk"  We already face the gold farmer risk as it is.
Agreed it would give an additional attack vector but.. The overall risk pattern would be unchanged imo.
And as said - It's not the actual (stated) reason for CCP saying no.
BIG Lottery |

Loney
CyberDyne R-D
|
Posted - 2009.09.25 01:39:00 -
[12]
Edited by: Loney on 25/09/2009 01:46:21
Originally by: TornSoul Which businesses in EVE move alot of ISK? So basically, who has to regularly (daily?) make alot of ISK payments to other players? Any others anyone can think of?
-----
If it *wasnt* a manual task to transfer ISK to another character - Would other existing businesses benefit (grow/gain more profit/more customers etc) if they did not have to do this manaully?
----
Awaiting some interesting suggestions.
1. I can't think of any other public ones off the top of my head besides EOH and EBANK. 2. I too have a drawer full of plans... that would greatly benefit from an automated system.
I see some people think that Lotteries, and Banking would be expanded... but If they were in fact able to do this I would like them to move it in a particular direction. Let me explain...
Summary of steps by CCP: 1. Pilot Insurance is made Mandatory! (Don't let pilots undock or launch ships from POS arrays unless they are insured, YES even MOMS & TITANS) 2. Automate a Payout System based off in game kill mails. (Should be easy as most in game mechanics already exist) 3. Remove the "isk facut" CCP insurance! (This solves a problem all by itself) 4. Create a simple yet usefull tool for PRIVATE corporatons to manage/track insurance. (This involves really no hard thought as it already exist ingame but is governed by CCP instead of players) 5. Let Private corporations selects the Terms of the insurance as in Amount and Length. (IE. 10m a Month, or 100m for 12 months, etc)
Its hard to put pages of details all summarized into 5 lines... but i hope you get the idea!
Thats my 2 isk for the day...
..
Check out our Website in game or out!
|

Selene D'Celeste
Caldari The D'Celeste Trading Company ISK Six
|
Posted - 2009.09.25 01:54:00 -
[13]
Hey TS. I think that as stated above, the thing that would benefit most from this being available would be the fabled "market services" that EBANK once spoke of, and that everyone since has wanted to do but has never done. Some day ....
Even then such services are not impossible. I don't think bank or poker room have -that- many payments out on average. For a bank-type business you can reduce cashouts via fees and other limitations (such as term-based deposits). For something like market services you really don't need -that- many cashouts since ISK can virtually flow from user accounts to business accounts, and it would only be transferred in bulk between the businesses (bank and webshop).
As for EOH, I'd say it's on average 30-40 cashouts a day. There are slow and busy periods though so it does fluctuate a bit. I'd be surprised if any business needed to do more than 50 cashouts in a day on average. Most are probably in the 10-20 range at max.
|

Katiana Swan
|
Posted - 2009.09.25 02:48:00 -
[14]
The only problem I see with this, if the coding is buggy and a hole was found in it, it could be exploited within seconds, the owner wouldn't know until next checking. With manual transactions it means each can be independently verified.
I do see the huge benefits that could be available having this possible but it could potentially cost a lot of isk. This isn't the game designers problem but it suddenly opens up the potential for lawsuits when websites are hacked and virtual assets are stolen. From what I have seen, the eve game designers try to steer as far away as possible from anything with potential to go this far.
|

HawkBlade
|
Posted - 2009.09.25 03:00:00 -
[15]
Originally by: Katiana Swan This isn't the game designers problem but it suddenly opens up the potential for lawsuits when websites are hacked and virtual assets are stolen.
Hacking is, depending on locality, its own crime and should be handled as such. Though I'll admit, most localities handled it like it is a bad joke. There is no lawsuit potential, against CCP, if this should happen. Terms of service have been hammered at, expounded upon, and debated by crap house lawyers ad infinitum, ad nuaseum. (sickeningly forever for the crap house lawyers amongst us) Even if the TOS was remotely inapplicable ultimately, or at least as far as US copyright laws are concerned, all items belong to CCP. Even services like Eve Info survive by CCP's sufferance so all the material is derivative (though fair use) and thus belongs to the owner. Eve Info only owns it domain and the website coding (if that). So, any crap house lawyers want to waste our time displaying thier thoughts or lack thereof? Originally by: Katiana Swan From what I have seen, the eve game designers try to steer as far away as possible from anything with potential to go this far.
Actually I'm hoping that the new ingame browser initiative brings better integration. It will of course need stronger authentication methods (obviously) but the dev blogs on this give much to look forward to in coming months/years/decades that it takes to get some dev time on it. Much like any "industrial" expansion or financial overhaul. @CCP - New Crap To Blow Up != Industrial Expansion. (For the slow amongst us.)
See my twitterings about Eve Online. Be the first to hear me toot.
|

Katiana Swan
|
Posted - 2009.09.25 03:11:00 -
[16]
Edited by: Katiana Swan on 25/09/2009 03:11:10 edit: so sorry i killed the forum
Maybe the game designers could come up with some less risky options, such as the ability to make batch payments. For example much like the batch emails requiring the separator colon, the same thing with payments.
One could have their services output a text document showing something like:
katiana swan; tornsoul; hawkblade
In some sort of give money box one could simply copy paste the names and set the amount so everyone gets this amount of cash. It would be a lot easier for people doing bonds and ipos and some other services.
Seems less intrusive, less risky and quite simple from a coding perspective for both game devs and web developers (coding is already there for batch options as per the evemail batch sending).
It doesn't fix the problem with banks but it might lead to options for banks to have round number payment requirements. For example if eve-bank had a rule that all withdrawals had to be an integer of 10 million isk (ie 100-110-120-1120 etc) then the output text document might look something like:
Withdrawals: Katiana Swan - 10m Tornsoul - 30m Hawkblade - 200m
katiana swan;tornsoul;tornsoul;tornsoul;hawkblade;hawkblade;hawkblade;hawkblade;hawkblade;hawkblade;hawkblade; hawkblade;hawkblade;hawkblade;hawkblade;hawkblade;hawkblade;hawkblade;hawkblade;hawkblade;hawkblade; hawkblade;hawkblade;hawkblade
Would make the bank teller job easier as they just copy paste and voila, all withdrawals completed within 2 minutes of logging in.
|

Selene D'Celeste
Caldari The D'Celeste Trading Company ISK Six
|
Posted - 2009.09.25 04:33:00 -
[17]
There are some ways they could make life easier. For example, the current IGB supports a function that opens an evemail in game with fields filled out by clicking on a link. This could be done for a wallet transfer, but would still require someone to click 'send' just like the evemail. If nothing else this would probably remove 90% of the time spent processing cashouts for sites that can generate lists of links. However as stated above, it is unlikely we will see any service with such a high demand for cashouts anytime in the near future.
|

Signore Kaeota
Caldari Caelum Incognitum
|
Posted - 2009.09.25 05:24:00 -
[18]
Edited by: Signore Kaeota on 25/09/2009 05:25:01
Originally by: Katiana Swan Edited by: Katiana Swan on 25/09/2009 03:11:10 edit: so sorry i killed the forum
Maybe the game designers could come up with some less risky options, such as the ability to make batch payments. For example much like the batch emails requiring the separator colon, the same thing with payments.
One could have their services output a text document showing something like:
katiana swan; tornsoul; hawkblade
In some sort of give money box one could simply copy paste the names and set the amount so everyone gets this amount of cash. It would be a lot easier for people doing bonds and ipos and some other services.
Seems less intrusive, less risky and quite simple from a coding perspective for both game devs and web developers (coding is already there for batch options as per the evemail batch sending).
It doesn't fix the problem with banks but it might lead to options for banks to have round number payment requirements. For example if eve-bank had a rule that all withdrawals had to be an integer of 10 million isk (ie 100-110-120-1120 etc) then the output text document might look something like:
Withdrawals: Katiana Swan - 10m Tornsoul - 30m Hawkblade - 200m
katiana swan;tornsoul;tornsoul;tornsoul;hawkblade;hawkblade;hawkblade;hawkblade;hawkblade;hawkblade;hawkblade; hawkblade;hawkblade;hawkblade;hawkblade;hawkblade;hawkblade;hawkblade;hawkblade;hawkblade;hawkblade; hawkblade;hawkblade;hawkblade
Would make the bank teller job easier as they just copy paste and voila, all withdrawals completed within 2 minutes of logging in.
This idea is actually quite good. To take it even further, it's sickeningly easy to separate numbers and letters, one would even be able to do the following:
katiana swan;11;tornsoul;38;hawkblade;226
and the result would be: katiana swan receives 11 mil tornsoul receives 38 mil hawkblade receives 226 mil
From code perspective, this is actually a very simple addition (vary depending upon language), and doesn't have the flaws that an automated system would - e.g. there's no 'extra' flaws, if someone 'hacks' this system, they have your account.
EDIT: remembered numbers can be in user names, modified and fixed. -_-_-_-
I, Signore Kaeota, hereby apologise for any and all offence caused by the contents of this above post, and all others that I have written, or otherwise been responsible for.
-_-_-_ |

Teavan
First CityWide Change Bank New Eden Retail Federation
|
Posted - 2009.09.25 13:18:00 -
[19]
Hey TS, long time no talk.
My corp has implemented an API based payrolling system. API events are scanned and then a virtual account is credited based on a set of modifiers for that event (ie: production jobs are isk/hour, inversely multiplied by your skill time reduction factor, credited to account upon delivery). Corp members are then free to withdraw isk from their virtual account at any time (we reinvest in the meantime!) by contacting a director. These withdrawls are tagged and then automatically deducted from the virtual account via API.
There are literally hundreds to thousands of micropayments to these accounts each day. If we could automate this last part of the process, corp members would be delighted as it would be just like shooting a rat, instant gratification!
|

Gehnster
Gallente RED SUN RISING
|
Posted - 2009.09.25 15:16:00 -
[20]
This is something I was thinking about for the last couple weeks since more and more talk about Moondoggie.
I think a very simple system of just allowing people to click on a link in the IGB to receive money from a corp would be excellent. There are already ways to give money to a corp, we just need a way to receive money from the people implementing these services. You would just need to ensure that Corp A is actually giving money to Character B. I would think this could be done by manually saying somehow "Corp A is allowed to give payments to Character B in the future" and any time after that all you will need to to verify API keys from then on.
|

TornSoul
BIG Libertas Fidelitas
|
Posted - 2009.09.25 16:49:00 -
[21]
@Selene
Thanks for the numbers.
The alternative mechanism you propose, I have already suggested as a minimum over in the Moondoggie Feedback (new IGB) thread.
Do go over there and quote/sign it.
------
From the answers given sofar, it appears that my initial suspicion is correct - ie. *atm* there's not that many services "requering" the automated transfer functionality - But on the other hand an explosion of projects are being held back by the lack of it.
------
Sadly I think it's a pretty fair bet that we *wont* get the automated functionality (shouldnt stop us from keep pushing the issue though), so what can we do instead as a "workaround" to accomplish this?
===================================
Let me outline my own thoughts on that:
We need a centralized ISK holder(1), where you can then make "virtual accounts", that their API can then move ISK between (when services etc are bought/sold/traded/etc)
EBANK was getting close to becomming that place. It was still a far far way away though -- But it was getting there - As more and more accounts got opened. I think the last number I heard was something in the order of 6000 accounts (of which many ofc will have been idle).
Now 6000 accounts is far from being (near) ubiquitous in EVE, as a scheme like this really would require for it to work.
And even then, you can't expect everyone to trust any one given entity trying to fill this role.
-----
Which leads me to the following:
1)This however requires a centralised ISK holder
I said that above, to make the concept a bit easier to understand. But as I've argumented above, not everyone would trust any one entity.
So let's instead break it up. Instead of one central ISK holder (ISKH), lets have many.
But lets keep the _one_ API. Each ISKH would then interface with the API. And you could choose whatever ISKH you trust with your ISK.
This would allow corps or other organisations to run their own isolated thing (someone above mentioned various corp payouts), but they wouldnt have to create the API.
That's not all however! It's not a large step to let each ISKH interface with *each other* through the API - And to the end user it would be transparent. Each ISKH is free to decide which other ISKH's they trust (or if they simply want to run their own thing).
--------
Example : User A buys something from webshop B. A's account is however with a different ISKH than that of the webshop. So two things could happen 1: Either the purchase is denied (as theres no trust between the two ISKH's) or 2: The purchase is accepted, and both the User A's, and webshop B's (virtual) accounts are updated (via the API). At some later time the ISKH's transfer the actual ingame ISK between their ingame holding accounts.
The transfers between the ISKH's is a manual process. But it can now be batched. So one transfer of ISK (once or twice a day or whatever) will potentially take care of thousands of "webshop" transactions.
---
So in conclusion : Lots of ISKH's, tied together by an API, that also ties in the webshops.
---
It's by no means a perfect scheme, and some ISKH's can still decide to scam etc. But I think over time, a number of ISKH's will emerge that "everyone" trusts. It will take time however...
And it might not even take of either - But I would like to see it happen.
BIG Lottery |

TornSoul
BIG Libertas Fidelitas
|
Posted - 2009.09.25 17:27:00 -
[22]
I should perhaps mention that the above outlined scheme is based directly on RL (with one difference).
The ISKH's from above are the RL banks/Credit card issuers. The webshops are, well.. the webshops  The API is what in RL is called a "Payment Service Provider" (PSP).
In RL banks don't allow webshops to interface with them directly (unless you are a *very* large webshop). They simply dont have (want!) the support structure for dealing with all the webshops (they leave that to the PSP's instead)
And in general the webshops don't want to either, because each bank has thier own API and rules. It would be far too much work for stamp seller Smith to interface with all the banks. Instead Smith contacs a PSP, who has just one interface to Smith, and the PSP then takes care of all the nasty (different API's) business with the banks (there is some trust issues involved a well)
The various bank API's in RL, as opposed to the single one suggested above, is the only real difference.
In principle there would be no issue with allowing each EVE bank their own API, the API (PSP) would simply have to deal - But why complicate it?
(The above is a rather simplistic description of how things work, but is accurate enough for the purpose. As a side note : I used to work as a programmer for a PSP, doing all that nitty gritty stuff towards the banks ) BIG Lottery |

Haskell
Gallente
|
Posted - 2009.09.25 18:51:00 -
[23]
Originally by: TornSoul
[a federated network of independent ISK holders/tellers]
Interesting. And very inspiring. So here are some follow-up thoughts:
Let's assume User Alice has an account with ISKH Claire and Webshop Bob's Holoreel Shop has an account with ISKH Dan, and Alice trusts Claire and Bob trusts Dan. Also, ISKH Claire has a cooperation agreement with ISKH Dan.
To reiterate the example, if Alice wants to buy a holoreel from Bob, she puts money in her account and performs the purchase with Bob. Claire debits Alice's account, and Dan credits Bob's account with the amount. This happens fully automated through an API.
As Claire accumulates liabilities with Dan, they have to clear the debt from time to time. The advantage is that this can be done in bulk, although still manually. Alice and Bob may want to withdraw money from their accounts which needs to be done manually as well.
What's the incentive to participate? I think the webshop example might be the wrong example here. Alice could wire the ISK directly to Bob, and Bob's webshop would note the purchase by polling the EVE API. But, let's say, Bob operates a slot machine ("Send me 100 ISK and I send you 400 ISK back. Not. Once in a while.").
Then the incentive for Bob to participate would be huge: he doesn't want to spend all day paying out units of 400 ISK. He would even be willing to pay some fee to have this done by someone else. That's the incentive for Claire and Dan. Both make money by offering virtual accounts, transferring ISK to other ISK holders and paying out ISK at least once every 48 hours. Alice's incentive, finally, is to be able to play the slot machines. 
There are two places where trust comes into play: the trust between ISK holders and account holders, and the trust between ISK holders. To make the idea really usable for users and slot machine owners, the ISK holders would need to have as many agreements with other ISK holders as possible.
The risk is that given trust may turn out to be unjustified. If Claire decides to scam, all of Alice's deposits will be lost and the outstanding liabilities with Dan will be defaulted. So the question is: how can risk be minimized in the presence of rogue ISK holders? (And there will be lots of ISK holders, as there's nothing that stops one to become one, and all ISK holders should have agreements with each other to make this usable.)
* Alice may be able to minimize the risk by spreading her money out at multiple ISK holders.
* Other ISK holders can limit the risk by limiting the amount of outstanding liabilities. ISK holders could also be required to deposit a collateral at a trusted third party so payments will be "insured" up to some amount.
That's what I've come up with so far.  |

TornSoul
BIG Libertas Fidelitas
|
Posted - 2009.09.25 21:32:00 -
[24]
I think we just might have overloaded everyone 
BIG Lottery |

Selene D'Celeste
Caldari The D'Celeste Trading Company ISK Six
|
Posted - 2009.09.26 04:04:00 -
[25]
To be fair, it's not the cashout automation that is holding anything back. It's the sheer size and complexity of developing such a system for arguable returns. Also it's a huge time sink. Despite the amazing things we have done in MD, nothing that has been hugely successful happened overnight, and anything shiny has taken a lot of time and sacrifice by those that worked on it, be that a fancy business or a nice piece of market software.
We will see market services before another two years are out, I guarantee it. And we will see things that almost no one has thought of yet. It simply takes time. I am just excited that these kinds of ideas are starting to spill across the entire forum, and aren't just possible businesses whispered about in back rooms.
|

TornSoul
BIG Libertas Fidelitas
|
Posted - 2009.09.26 20:23:00 -
[26]
Originally by: Haskell What's the incentive to participate? I think the webshop example might be the wrong example here. Alice could wire the ISK directly to Bob, and Bob's webshop would note the purchase by polling the EVE API.
But this takes time, due to the API cashe times. Anymore than a couple of minutes and it's no good.
Instant (as with the PSP solution) is exponentially better.
Ofc another solution to this would be to get rid of the EVE API cashe (not going to happen). And it wouldnt solve all problems anyhow - See below.
Originally by: Selene D'Celeste To be fair, it's not the cashout automation that is holding anything back.
Yes and no. *Currently* it isnt. But given a solution as outlined above, I can easily see the numbers explode, an thus automation being a must.
Also, even with a removed EVE API cashe, to wire ISK you would have to be logged in (could be solved by allowing us to transfer ISK from our own wallet via the EVE API - Again, not going to happen)
Imagine a news service - Which could perhaps even be read on your mobile. Bit tedious having to log in to wire a small sum, to be able to read (imagine they charge 10 ISK per read or similar) Imagine a news service that could actually (in a practical fashion) make some ISK (to pay reporters etc) for their service!
Lots of other examples along the same vein.
Accessability and speed being the key elements.
BIG Lottery |

Haskell
Gallente
|
Posted - 2009.09.26 23:04:00 -
[27]
Sure, a webshop would benefit a lot from this, too. But I think I'll badly need to build me a slot machine if this idea becomes reality 
I agree implementing this system is a lot of work and won't be done in one day. But I think the technical problems are solvable. While there are some things that are not going to happen (such as an API for transferring money), chances are good to get some improvements in areas that can be addressed. A show-stopper for many plans in my drawer is the lack of a simple, secure and usable method to authenticate characters, and CCP Ronin said they're in the process of researching a method to secure the IGB HTTP headers.
The biggest problem I see so far is the trust between ISK holders.
Alice has deposited ISK with Claire and buys a holoreel in Bob's webshop for 225 ISK. Bob delivers immediately after the transaction, Alice has one holoreel, Dan has booked 225 ISK into Bob's account and Claire needs to manually transfer 225 ISK to Dan. The risk is obviously that Claire scams, leaving Dan with the option to accept the loss or pass the scam on to Bob.
How far do can you trust other ISK holders? How much outstanding ISK would you accept before the other ISK holder has to clear debts? How do you prevent ISK holders from repeatedly going to your limit and run? In other words: How safe is my money if I decide to trust you (not the other ISK holders)?
|

TornSoul
BIG Libertas Fidelitas
|
Posted - 2009.09.27 00:49:00 -
[28]
Originally by: Haskell
The biggest problem I see so far is the trust between ISK holders.
Agreed.
Which is why I believe there will be 2,3,4 or so BIG ones, that each trust each other, and a lot of smaller ones (that are trusted by no one, nor do they necessarily want/need to be).
The smaller ones, mostly being used for corp affairs and the like.
The ability to have a lot of smaller ones "on the edges" is imo a strength, as it will get people used to the process. A sort of "grass root movement" that will benefit the overall system over time. BIG Lottery |

Haskell
Gallente
|
Posted - 2009.09.27 13:24:00 -
[29]
Originally by: TornSoul Which is why I believe there will be 2,3,4 or so BIG ones, that each trust each other
So basically a bank that doesn't pay interest? I'm sure everyone in EBANK trusted Ricdic most of the time.
|

TornSoul
BIG Libertas Fidelitas
|
Posted - 2009.09.27 15:47:00 -
[30]
Originally by: Haskell
Originally by: TornSoul Which is why I believe there will be 2,3,4 or so BIG ones, that each trust each other
So basically a bank that doesn't pay interest? I'm sure everyone in EBANK trusted Ricdic most of the time.
Not exactly sure what you mean...?
Each bank (ISKH) can set their rates as they wish. And perhaps offer other services, that makes them attractive to customers.
And trust in whoever runs the bank would naturally be a parameter as well.
BIG Lottery |
| |
|
| Pages: [1] 2 :: one page |
| First page | Previous page | Next page | Last page |